Server push: polling, long polling, SSE, WebSockets
The ways a server can tell a client that something changed, and how update rate, latency needs and who-knows-what decide between them.
Communication
Learn it
HTTP is request-response: the client asks, the server answers. When something changes on the server (a job finished, a message arrived), the client doesn't know to ask. The question is how the change reaches the client, how quickly, and at what cost.
Method How it works Cost and character Polling client asks every n seconds average delay n/2; one request per client per interval; stateless and deploy-proof Long polling server holds the request until something changes near-instant, but each waiting client holds a connection Server-Sent Events one long HTTP response streams events one direction; reconnects with Last-Event-IDWebSockets full-duplex connection after an upgrade cheap messages both ways; you own reconnects and heartbeats Work it out
A client polls every 8 seconds. On average, how many seconds after a change does it notice?The choice is rarely about the protocol. Three questions decide it:
- How often does state change, and how quickly must the client see it?
- Does the client also stream data to the server? Only then does full duplex matter.
- Who knows about the change? If a worker updates the database and the client is connected to an API server, that server must find out via pub/sub or by polling the database itself.
Check
A status page changes about 4 times over 20 minutes, and a few seconds' delay is fine. What fits best?
Quick reference
The same ideas, condensed for revision.
How it goes wrong
- Missed events on reconnect
- Events sent while the client was disconnected are lost unless the protocol can resume from a position.
- Polling storms
- Thousands of clients polling in sync, for example after a deploy, create load spikes. Jitter and backoff help.
- Fan-out gap
- The process that changed state is not the one holding the client's connection, and nothing bridges them.
Instead, consider
- Email or mobile push notification
- The user is probably not looking at the page when the event happens.
- Webhooks
- The client is another server that can receive HTTP requests.
In practice
- setInterval + GET
- Polling; add jitter and stop when the tab is hidden.
- EventSource (SSE)
- Built-in browser reconnect with Last-Event-ID.
- WebSocket
- Bring your own heartbeats, reconnection and resume protocol.
- Managed realtime services
- Hosted pub/sub with client SDKs; they own connections and fan-out.
It assumes
- Persistent connections require infrastructure (load balancers, proxies) that supports them and does not cut idle connections.
- Clients reconnect, so the server must be able to resume or resynchronize.
Explain it in your own words
Where you practise it
Further reading
Engineers describing it in systems they run.
- How Convex Works
Convex · Sujay Jayakar · Post, Apr 2024
A walk through a reactive database from the inside: the transaction log, read sets, optimistic concurrency, and how a write finds the subscriptions it affects.
- Uber's Real-Time Push Platform
Uber · Madan Thangavelu and others · Post, Dec 2020
Why polling was replaced, and the delivery problems push brought with it: resuming after a dropped connection, and knowing what actually arrived.
Related concepts
- Persistent connections
Long-lived connections such as WebSockets turn a stateless request tier into one that holds per-client state, with consequences for routing, deploys and failure detection.
- Publish/subscribe
Decoupling senders from receivers by topic: a publisher sends once and every current subscriber receives a copy.
- Webhooks
HTTP callbacks from another system: delivered at least once, possibly out of order, possibly never. Handle them as hints, not truth.