"WebSockets vs Server-Sent Events vs long polling"
Choosing how a server pushes updates to clients: short polling, long polling, Server-Sent Events and WebSockets compared on direction, latency, overhead, proxies, scaling and mobile behaviour, plus WebTransport and push notifications, with a decision guide for interviews.
Reading is half of it. See this used in a real interview: walk through Design WhatsApp →
Chat messages, live scores, notifications, collaborative cursors and streamed AI responses all need the server to send data to the client without waiting to be asked. HTTP was designed for the client to ask, so several techniques exist, each with different costs. Interviewers expect you to pick one and justify it in a sentence. This guide gives you that sentence.
The options
Short polling: the client asks every few seconds ("anything new?"). Simple and works everywhere, but wastes requests when nothing changed and adds up to one polling interval of delay.
Long polling: the client asks; the server holds the request open until there is something to send (or a timeout, say 30 seconds), then responds; the client immediately asks again. Near real-time with plain HTTP, but each message costs a full request and response, and ordering across reconnects needs care.
Server-Sent Events (SSE): the client opens one HTTP request; the server keeps it open and streams events as text (text/event-stream). The browser's EventSource reconnects automatically and resumes with Last-Event-ID. One direction only: server to client.
WebSockets: an HTTP request upgrades to a persistent, full-duplex connection; both sides send messages at any time with tiny framing overhead. The most flexible and the most to manage.
Comparison
| Short polling | Long polling | SSE | WebSockets | |
|---|---|---|---|---|
| Direction | client pulls | server responds when ready | server to client | both ways |
| Latency | up to the interval | low | low | lowest |
| Overhead per message | full request | full request | small | very small |
| Protocol | plain HTTP | plain HTTP | plain HTTP streaming | upgraded connection |
| Reconnect and resume | trivial | manual | built in (Last-Event-ID) | manual |
| Proxies and firewalls | no issues | mostly fine | mostly fine (disable buffering) | occasionally blocked |
| Binary data | yes | yes | text only | yes |
| Best for | infrequent updates, simplest setup | fallback, legacy environments | feeds, notifications, streamed AI output, dashboards | chat, games, collaboration, anything bidirectional and frequent |
Choosing
- The client mostly listens, and sends occasionally: SSE for the stream plus normal HTTP requests for the rare sends. Simple, works with existing HTTP infrastructure and auth, auto-reconnects. Streaming LLM responses commonly use it. See LLM systems.
- The client and server both send frequently with low latency (chat typing, cursors, game input): WebSockets. See Design WhatsApp and Design Google Docs.
- Updates are rare or freshness of a minute is fine: polling, possibly with ETags so unchanged responses are cheap. See HTTP caching.
- Long polling as a fallback where persistent connections are blocked.
Scaling persistent connections
SSE and WebSockets both mean many long-lived connections:
- Run dedicated connection gateways sized by connection count and memory, not CPU.
- Route messages to the gateway holding each user's connection through a registry or pub/sub.
- Use heartbeats to detect dead connections, and jittered backoff on reconnect to avoid storms.
- Load-balance on connection count and drain gently on deploys.
See presence and connection management and load balancing.
HTTP/2 and HTTP/3
Under HTTP/1.1, browsers limit connections per domain (about six), which constrained multiple SSE streams. HTTP/2 multiplexes many streams over one connection, removing that limit. WebTransport over HTTP/3 offers bidirectional streams and unreliable datagrams, useful for games and media, though support is still less universal than WebSockets.
Mobile apps
A persistent connection works only while the app is in the foreground; operating systems suspend background sockets to save battery. Combine:
- WebSocket or SSE while the app is open.
- Push notifications (APNs, FCM) to wake the user or app when it is closed.
- A sync on reopen that fetches everything missed from the server's durable store.
See push notifications and mobile system design.
Reliability is your job
None of these transports guarantees delivery across disconnects. Store messages durably, give them sequence numbers or ids, and let clients resume from the last one they saw. The transport is just the fast path. See real-time systems.
In the interview
"Clients keep a WebSocket to a gateway tier for bidirectional chat; messages are persisted first and pushed through the socket, with push notifications when the app is backgrounded and catch-up by sequence number on reconnect." Or, for a one-way feed: "SSE, because updates flow one way and it reuses our HTTP stack with automatic resume."
Checklist
- Direction and frequency of messages decide the transport.
- SSE for one-way streams; WebSockets for frequent two-way traffic; polling for rare updates.
- Connection gateways, routing, heartbeats and reconnect backoff.
- Push notifications for backgrounded mobile apps.
- Durable messages with resume by id; the transport is not the source of truth.