Polling vs long polling vs WebSockets: an interactive real-time simulator

To show users new messages as they happen, a server can be polled (asked every few seconds), long polled (asked, and the answer held back until there is one), or keep a connection open to push on: server-sent events one way, WebSockets both ways. They trade delivery delay, wasted requests and bandwidth against the cost of holding a connection open for every user.

The playground follows one user’s minute under each method, and adds up the whole fleet. Change how many users there are, how often each gets a message, and how often short polling asks.

Short polling: simple, slow and wasteful

Asking every 5 seconds delivers a message 2.5 seconds late on average, and when messages are rare almost every answer is “nothing new”: with 100,000 users getting a message a minute, 20,000 requests a second, 92% of them empty, each with hundreds of bytes of headers. Polling faster cuts the delay and multiplies the waste. It is still the right choice when a few seconds’ delay is fine and the infrastructure must stay plain: a dashboard refreshing every 30 seconds.

Long polling: real time over plain HTTP

The client asks, and the server holds the request open until it has something or a timeout, typically 30 seconds, passes; then the client asks again. Messages arrive about as fast as with a socket, and it works through any proxy or firewall that allows HTTP. The costs: every message still pays for a full request, the server holds an open request per user, and a message sent while the client is reconnecting waits a round trip.

Server-sent events and WebSockets: one connection, pushed

Both keep one connection per user and push messages as they arrive, with a few bytes of framing instead of HTTP headers. Server-sent events are a long-lived HTTP response the server writes to: one direction only, text only, but the browser reconnects by itself and resumes from the last event id. WebSockets are a two-way channel for text or binary frames, the choice when the client also sends a lot, as in chat, games or collaborative editing, but reconnecting and resuming are left to your code.

What holding connections costs

A million open connections is a million file descriptors, buffers and keepalive timers spread across your gateway fleet, and every deploy or crash drops them all at once and invites a reconnect storm, so clients must reconnect with jittered backoff. Load balancers must allow long-lived connections; sticky routing or a pub/sub layer is needed to reach the server that holds a given user’s connection. Mobile apps in the background cannot hold sockets at all, which is what push notifications are for.

The three in code

// server-sent events: the browser reconnects and resumes on its own
const events = new EventSource('/inbox/stream');           // sends Last-Event-ID on reconnect
events.onmessage = (e) => render(JSON.parse(e.data));

// WebSocket: two-way, but reconnecting and resuming are up to you
function connect(lastSeen) {
  const ws = new WebSocket(`wss://chat.example.com/ws?since=${lastSeen}`);
  ws.onmessage = (e) => { const m = JSON.parse(e.data); lastSeen = m.id; render(m); };
  ws.onclose = () => setTimeout(() => connect(lastSeen), backoffWithJitter());
  return ws;
}

// long polling: ask, wait up to 30 s, ask again
async function poll(since) {
  for (;;) {
    const res = await fetch(`/inbox?since=${since}&wait=30`);   // the server holds it open
    for (const m of await res.json()) { since = m.id; render(m); }
  }
}

In a system design interview

Pick by direction and scale, and say how messages reach the right connection: “Clients hold a WebSocket to a gateway tier. When a message is written, the chat service publishes it to the recipient’s channel in Redis pub/sub, and whichever gateway holds that user’s socket pushes it. Clients reconnect with backoff and jitter, passing the last message id so nothing is missed; offline users get a push notification instead.” Expect the follow-ups: how many connections one gateway holds, what happens on deploys, and presence.

Read the guide to WebSockets, SSE and long polling or presence and connection management, or watch a strong candidate design WhatsApp.

Questions people ask