Real-Time Updates: Polling, Long Polling, SSE, and WebSockets

Your chat app polls GET /messages every two seconds. It works — messages show up, eventually. But two things are wrong and both get worse with success. Users feel the app is slow: a message sent the instant after a poll sits invisible for nearly two seconds. And your database feels the app is huge: ten thousand idle users generate five thousand queries a second, and the overwhelming majority return an empty array. You’re paying full price — a query, a round trip, a set of HTTP headers — to be told “nothing happened,” over and over.

The instinct is to poll faster. That makes the lag better and the load catastrophically worse. The real problem is deeper than the interval.

The ladder: each rung fixes the one below it

There isn’t one answer; there’s a progression. Each technique removes a specific flaw of the previous one, and each adds its own cost. Knowing the ladder means you can name the cheapest rung that actually meets your need.

• Short polling — the client asks on a timer. Dead simple, works everywhere, degrades to garbage: most requests are wasted, and staleness is bounded only by the interval.
• Long polling — the client asks, and the server holds the request open until it has data (or a timeout fires ~30s later). Near-real-time over plain HTTP. But each connection cycle delivers at most one batch, then you pay the full HTTP handshake and headers to re-open.
• Server-Sent Events (SSE) — one long-lived HTTP response the server streams events down, forever. Server→client only, but with auto-reconnect and event-ID resume baked into the browser. Perfect for feeds, notifications, dashboards, price tickers.
• WebSockets — after an HTTP Upgrade handshake, the TCP connection becomes a full-duplex, low-overhead pipe. Both sides push, frames can be binary or text. Built for chat, gaming, and collaborative editing.

Four flows, one picture

The difference between the four is entirely about who holds the connection open, and for how long. Short and long polling live inside the request/response box; SSE and WebSockets escape it.

From here the members-only continuation walks the four transports in code side by side, shows why an SSE server is barely any code at all, unpacks the SSE-vs-WebSockets decision most interviews actually want, and then confronts the scaling twist — sticky routing and the pub/sub backplane that fan-out demands — with a runnable backplane snippet, real-world teardowns, an interview corner, and a full quiz.