21. Polling vs WebSockets vs Push
1
The picture to keep in your head2
21.1 What's the problem: the server has news for you?3
21.2 What are the options?4
21.3 How do you scale millions of open connections?5
21.4 How do heartbeats, reconnects and missed messages work?6
21.5 How do you choose?7
Memory card and where the analogy breaks8
Practice: five levels9
Interview questions10
Solutions11
Sources12
Code lab21. Polling vs WebSockets vs Push
21.5 How do you choose?
3 min read+10 XP
At the gate: Out of the house? It's a note in the letterbox. Need to talk back and forth? Phone line. Just want to hear the news? Radio. Expecting one thing, sometime this afternoon? Call now and then.
In the system:
Figure: three questions pick the transport.
| Direction | Latency | Server cost | Works when app closed | Typical use | |
|---|---|---|---|---|---|
| Short polling | Client asks | Interval / 2 on average | Many requests, mostly empty | No | "Is my report ready?" |
| Long polling | Server → client | Near instant | One held request per user | No | Fallback |
| SSE | Server → client | Instant | One open connection per user | No | Tracking, scores, feeds, AI streaming |
| WebSocket | Both ways | Instant | One open, stateful connection per user | No | Chat, games, collaboration |
| Mobile push | Server → device | Seconds, not guaranteed | Calls to APNs/FCM | Yes | Alerts that bring users back |
Most real products combine them. The grocery app:
- Mobile push for "out for delivery" and "delivered" when the app is in the background.
- SSE (or a WebSocket) for the tracking screen while it's open, with the rider's position every few seconds.
- A normal GET whenever the screen opens, to load the current state, so nothing depends on every event arriving.
- If the app also has chat with the rider, a WebSocket for that screen.
Memory code: "Out? Push. Talking? WebSocket. Listening? SSE. Rarely? Poll."