WebSockets, SSE or polling?
“A dashboard needs live updates. Compare polling, long polling, server-sent events and WebSockets. What does each cost at 100,000 connected clients?”
What this tests
- Fit of each mechanism to update frequency and direction
- Resource arithmetic: connections, memory, fan-out at scale
- Stateful connections vs stateless services: what changes for load balancing and deploys
- Knowing that polling is often correct
Answers by level
Read the beginner answer first and notice what is missing.
Polling: the client asks every N seconds; simple, stateless, cacheable, and at 100,000 clients polling every 10 s that is 10,000 requests per second, most of which return "nothing changed" — with ETags those are cheap 304s. Long polling holds the request until there is data, cutting the empty responses but tying up a connection per client. SSE is a one-way stream over plain HTTP: server to client, auto-reconnect built in, works through most proxies, and is enough for a dashboard. WebSockets are bidirectional and persistent: needed when the client sends frequently too — chat, collaborative editing, games.
At 100,000 clients, SSE and WebSockets mean 100,000 open connections. Each is cheap in memory (tens of KB), so a few servers can hold them, but the service is now stateful: a deploy drops every connection and they all reconnect at once (thundering herd — needs jittered reconnect), the load balancer must support long-lived connections and idle timeouts, and fan-out of one update to 100,000 sockets across 10 servers needs a pub/sub layer (Redis, a broker) so each server relays to its own clients.
For a dashboard with updates every few seconds, polling with ETags or SSE is the honest choice. WebSockets buy bidirectionality the dashboard does not use and cost the operational complexity of stateful connections.
Green flags · Red flags
- Distinguishes the four mechanisms by direction, freshness and connection model
- Does the arithmetic at 100,000 clients (rps for polling, connections for streams)
- Names stateful-connection costs: deploy reconnect storm, LB idle timeouts, fan-out via pub/sub
- Prefers polling or SSE for a one-way dashboard
- Mentions reconnect jitter and resumable streams
- "Polling is inefficient; always use WebSockets for real-time."
- Ignores that persistent connections make the service stateful
- Has every server query the database to push the same update
- Cannot say what happens on deploy with 100,000 open sockets