# Polling, SSE and WebSockets

> Four ways to push updates to a client, and what each costs the server.

Concept · Networking & APIs · https://levelcode.org/concepts/realtime-transports

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-ID` to 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](https://levelcode.org/concepts/retries-with-backoff)).
- **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.