Keep-alive vs Long Polling

Keep-alive vs Long Polling

Why This Matters

Think of keep-alive like reusing the same phone line for multiple calls. Instead of hanging up and dialing again for each call, you keep the line open and make multiple calls. Long polling is like calling someone and staying on the line until they have something to tell you. Keep-alive reduces connection overhead, while long polling enables real-time updates.

This matters because creating TCP connections has overhead (three-way handshake). If you're making many requests, creating a new connection for each request is slow. Keep-alive reuses connections, reducing overhead. Long polling enables real-time updates without the overhead of constant polling, but it ties up server resources.

In interviews, when someone asks "How would you implement real-time updates?", they're testing whether you understand keep-alive, long polling, and WebSockets. Do you know when to use each? Do you understand the trade-offs? Most engineers don't. They just use polling and wonder why it's inefficient.

What Engineers Usually Get Wrong

Most engineers think "long polling is the same as keep-alive." But they're different. Keep-alive reuses TCP connections for multiple HTTP requests. Long polling is a technique where the server holds a request open until it has data to send. Keep-alive reduces connection overhead, while long polling enables real-time updates.

Engineers also don't understand that long polling ties up server resources. Each long-polling request holds a connection open. If you have 10,000 clients doing long polling, you have 10,000 open connections. This can exhaust server resources. WebSockets are often better for real-time updates because they're more efficient.

How This Breaks Systems in the Real World

A service was using long polling for real-time updates. Each client held a connection open for up to 30 seconds. With 10,000 clients, the service had 10,000 open connections. The server ran out of file descriptors. New connections were rejected. The service became unavailable. The fix? Use WebSockets instead of long polling. WebSockets are more efficient—one connection per client, bidirectional, and lower overhead.

Another story: A service was making many HTTP requests but wasn't using keep-alive. Each request created a new TCP connection. The three-way handshake overhead (50-100ms per request) added up. Response times were slow. The fix? Enable HTTP keep-alive. Reuse TCP connections for multiple requests. This reduced connection overhead significantly.

HTTP Keep-alive

Keep-alive reuses the same TCP connection for multiple HTTP requests.

Without Keep-alive

Request 1: TCP connection → Request → Response → Close
Request 2: TCP connection → Request → Response → Close
Request 3: TCP connection → Request → Response → Close

Overhead: 3-way handshake for each request

With Keep-alive

TCP connection (established once)
  Request 1 → Response 1
  Request 2 → Response 2
  Request 3 → Response 3
Connection stays open

Benefits: Reuse connection, reduce overhead

Long Polling

Long polling holds HTTP request open until server has data to send.

How Long Polling Works

1. Client sends request
2. Server holds request (doesn't respond immediately)
3. When data available: Server responds
4. Client immediately sends new request
5. Repeat

Use case: Real-time updates when WebSockets not available

Comparison

Examples

HTTP Keep-alive

1 

Long Polling

1 

Long Polling Server

1 

Common Pitfalls

• Keep-alive timeout: Connection closed prematurely. Fix: Configure appropriate timeout
• Long polling connections: Too many held connections. Fix: Limit connections, use timeouts
• Not using keep-alive: Wasting resources. Fix: Enable keep-alive for multiple requests
• Long polling overhead: High server load. Fix: Use WebSockets for better performance

Interview Questions

Beginner

Q: What is HTTP keep-alive and how does it differ from long polling?

A:

HTTP Keep-alive:

Reuses TCP connection for multiple requests:

TCP connection (established once)
  Request 1 → Response 1
  Request 2 → Response 2
  Request 3 → Response 3
Connection stays open

Benefits:

• Reduced overhead: No new handshake per request
• Faster: Reuse existing connection
• Efficient: Multiple requests on one connection

Long Polling:

Holds HTTP request open until data available:

1. Client sends request
2. Server holds request (doesn't respond)
3. When data available: Server responds
4. Client immediately sends new request

Use case: Real-time updates (when WebSockets not available)

Differences:

Intermediate

Q: Explain how long polling works and when you would use it vs WebSockets.

A:

Long Polling Process:

1. Client sends request

   GET /updates
   

2. Server holds request

   Server doesn't respond immediately
   Waits for data (up to timeout)
   

3. Data available

   Server responds with data
   

4. Client immediately requests again

   GET /updates (new request)
   

Example:

1 

Long Polling vs WebSockets:

When to use:

• Long polling: Simple, works everywhere, WebSockets not available
• WebSockets: Real-time, low latency, bidirectional

Senior

Q: Design a system that uses both keep-alive and long polling efficiently. How do you manage connections, handle timeouts, and optimize for performance?

A:

1 

Features:

1. Keep-alive: Reuse connections for regular requests
2. Long polling: Real-time updates
3. Connection management: Optimize, limit, timeout

Failure Stories You'll Recognize

The Exhausted Connections: A service was using long polling for real-time updates. Each client held a connection open for up to 30 seconds. With 10,000 clients, the service had 10,000 open connections. The server ran out of file descriptors. New connections were rejected. The service became unavailable. The fix? Use WebSockets instead of long polling. WebSockets are more efficient—one connection per client, bidirectional, and lower overhead.

The Slow Requests: A service was making many HTTP requests but wasn't using keep-alive. Each request created a new TCP connection. The three-way handshake overhead (50-100ms per request) added up. Response times were slow. The fix? Enable HTTP keep-alive. Reuse TCP connections for multiple requests. This reduced connection overhead significantly.

The Resource Exhaustion: A service was using long polling but didn't set connection limits. During a traffic spike, 50,000 clients were doing long polling simultaneously. The server ran out of resources (memory, file descriptors). The service crashed. The fix? Set connection limits. Use load balancers to distribute connections. Or use WebSockets, which are more efficient.

What Interviewers Are Really Testing

They want to hear you talk about keep-alive and long polling as tools with trade-offs, not just techniques. Junior engineers say "keep-alive reuses connections, long polling holds requests open." Senior engineers say "keep-alive reduces connection overhead by reusing TCP connections. Long polling enables real-time updates but ties up server resources. For real-time updates, WebSockets are often better—more efficient and bidirectional."

When they ask "How would you implement real-time updates?", they're testing:

• Do you understand keep-alive, long polling, and WebSockets?
• Do you know when to use each?
• Can you optimize connection usage?