Concept · Networking & APIs
Polling, SSE and WebSockets
Four ways to push updates to a client, and what each costs the server.
3 minlong pollingserver-sent eventswebsocket
HTTP is request–response: the client asks, the server answers. Real-time features — chat, notifications, live dashboards, collaborative editing — need the server to send data when something happens. Four techniques, from simplest to most capable:
| Technique | How it works | Latency | Server cost | Direction |
|---|---|---|---|---|
| Short polling | Client asks every N seconds | Up to N seconds | A request per client per interval, mostly empty | Client → server |
| Long polling | Client asks; server holds the request until there's news or a timeout, then the client asks again | Low | One held request per client; a new request after each message | Server → client (emulated) |
| Server-Sent Events (SSE) | One long-lived HTTP response streaming data: lines | Low | One open connection per client | Server → client |
| WebSockets | HTTP upgrade to a persistent, full-duplex connection | Lowest | One open connection per client, with state | Both ways |
Choosing
- Polling is fine when updates are infrequent and a few seconds' delay is acceptable (a job-status page). It's the simplest and works through every proxy.
- SSE suits one-way streams: notifications, live scores, streaming LLM output. It's plain HTTP, so it works with existing auth, compression and HTTP/2 multiplexing, and browsers reconnect automatically (with
Last-Event-IDto resume). - WebSockets suit two-way, high-frequency traffic: chat, multiplayer games, collaborative editors.
What persistent connections change
- The connection tier becomes stateful. A server must know which connections it holds, and the rest of the system needs a registry to find the server holding a given user's connection (see the System Design roadmap's chat lesson).
- Capacity is measured in concurrent connections, often hundreds of thousands per server, limited by memory and file descriptors more than CPU.
- Reconnect storms. When a server restarts, all its clients reconnect at once; clients must back off with jitter (retries, backoff and jitter).
- Load balancers and proxies need long idle timeouts, and the protocol should include heartbeats so dead connections are detected.
- Deploys must drain connections gradually rather than dropping them all.