Skip to content

Trade-offs · Foundations

Polling vs long polling vs SSE vs WebSockets

Which way to push live updates to a browser or phone, with request counts, server counts and the delay each method gives.

Asked at: SDE-1SDE-2Senior

The decision

HTTP works one way round: the client asks and the server answers. To show live news, such as a score, you need a trick. Polling asks again on a timer. Long polling asks, and the server holds the request open until there is news. Server-Sent Events (SSE) keep one answer open, and the server writes each news item into it. A WebSocket is a connection that carries messages both ways. You choose by how fresh the data must be, how many clients you have, and who talks.

Choose polling when

  • A delay of several seconds is fine, and the number of clients is small.
  • You want the simplest code, with no open connections.
  • The data changes rarely, so a gap of 30 seconds or more is enough.

Choose long polling when

  • You need near-instant news, but an old proxy or library blocks WebSockets and SSE.
  • You must support clients that have neither.
  • A full request for each news item is an acceptable cost.

Choose SSE when

  • News goes only from server to client: scores, prices, notifications, progress bars.
  • You want automatic reconnect. The browser reconnects and sends the id of the last event it saw, so the server can resume.
  • Normal HTTP tools and load balancers should keep working.

Choose WebSockets when

  • Both sides send often: chat, shared editing, multiplayer games, bidding.
  • Messages are small and frequent, so repeated HTTP headers would cost too much.
  • You accept more code: your own reconnect, heartbeats and login checks.

The numbers that change the answer

Assumptions for a live cricket score:

  • 500,000 viewers. The score changes every 30 seconds.
  • A poll costs 800 bytes and 1 ms of CPU. An SSE event is 120 bytes.
  • A server has 4 cores and runs 70% busy: 4 x 1,000 / 1 x 0.7 = 2,800 polls per second.
  • A server holds 50,000 open connections.
MethodNew requests per secondOpen connectionsServers (with 1 spare)
Polling every 5 s500,000 / 5 = 100,000none100,000 / 2,800 = 35.7, so 36 + 1 = 37
Long polling500,000 / 30 = 16,667500,000500,000 / 50,000 = 10, so 10 + 1 = 11
SSEalmost none500,00010 + 1 = 11
WebSocketsalmost none500,00010 + 1 = 11
  • Polling delay: 2.5 seconds on average (half the gap), 5 at most. A poll finds news 5 / 30 = 1/6 of the time, so 83% of polls are empty. Data = 100,000 x 800 bytes = 80 MB per second.
  • SSE data: one score reaches 500,000 x 120 bytes = 60 MB, once per 30 seconds, which is 2 MB per second on average. That is 80 / 2 = 40 times less than polling.
  • Average delay is half of the polling gap. For a 1 second delay you need a gap of 2 seconds, which is 500,000 / 2 = 250,000 requests per second. Open connections win.
  • Client sends: Assumption: 100,000 chat users each send one message every 10 seconds. With SSE plus a normal POST, that is 10,000 POSTs per second x 800 bytes = 8 MB per second. With WebSockets at 120 bytes per message (Assumption) it is 1.2 MB per second.

What breaks with each choice

  • Polling: load grows with the number of viewers, even when nothing changes. Fix: a longer gap, or move to SSE when polling needs more than a few servers.
  • Long polling: each news item still costs a full request with headers, and held requests use memory.
  • SSE: on HTTP/1 a browser allows 6 open connections for each site, so several tabs can block each other. On HTTP/2 the default is 100 streams (see Sources). Proxies may close idle connections, so send a comment line every 15 seconds.
  • WebSockets: you write reconnect, heartbeat and login checks yourself. Restarts hurt most. A server with 500,000 / 11 = 45,455 clients restarts, and they all reconnect together. If each waits a random 0 to 10 seconds, that is 4,545 new connections per second. Fix: random delay (jitter) on reconnect.

What it costs

  • Assumption: polling takes 1 day to build, SSE 1 week, WebSockets 3 weeks including reconnect, login and load tests.
  • In the example, 37 servers for polling against 11 for the others is 26 fewer servers. You must still watch connections.
  • Moving from polling to SSE later is cheap if the update comes from one event stream. Keep the update format the same.

How each level answers

SDE-1: Polling asks again and again. Long polling waits for the answer. SSE lets the server push one way. A WebSocket lets both sides send.

SDE-2: For a live score I pick SSE, because data goes only to the client, it reconnects by itself, and it works with normal HTTP. For chat I pick WebSockets, because both sides send often.

Senior: For 500,000 viewers, polling every 5 seconds is 100,000 requests per second and 37 servers, and 83% of polls are empty. SSE is 11 servers. The failure is a reconnect storm after a restart, so I add jitter of 0 to 10 seconds and use least-connections balancing. The fallback is polling every 10 seconds, which is 50,000 requests per second.

Staff: The business question is how late the news may be, and what one second of delay costs. I start with polling at 10 seconds behind a feature flag, because it ships in a day. When polling needs more than a few servers, I move to SSE. A platform team owns the connection layer. I measure p95 (the time within which 95 of 100 requests finish) time from event to screen, open connections per server and reconnects per minute.

Say it in the interview

"For a live score I use SSE, because data only goes to the client and the browser reconnects by itself. With 500,000 viewers, polling every 5 seconds is 100,000 requests per second, while SSE needs about 11 servers to hold the connections. For chat I use WebSockets with a random delay on reconnect, so a restart does not cause a storm."

Common mistakes

  • Choosing WebSockets for every live feature. It is wrong when data goes one way, because SSE is simpler and reconnects for free.
  • Forgetting the cost of open connections. Each one uses memory and a slot on the load balancer, so plan connections per server.
  • Using round-robin balancing for long connections. It does not see how many connections a server holds, so one server can fill up. Use least connections.

Sources

Understand the trade-off. Practise explaining your choice.

In an AI mock interview, the interviewer can push on a choice like this one: it changes a number and asks if your answer still holds.

See the mock interviewsAll trade-offs