WebSockets vs Long Polling vs SSE: Real-Time on the Web

🔵 Fundamentals · Fresher-friendly → 🟠 senior nuance

Chat messages, live scores, stock tickers, "someone is typing…", collaborative docs — how does the server push new data to your browser the instant it happens? Plain HTTP can't: the browser asks, the server answers, done. The server has no way to speak up on its own. Getting around that limitation is the whole story of real-time on the web, and it comes down to four techniques: polling, long polling, Server-Sent Events, and WebSockets. Let's understand each and, crucially, when to pick which — a favourite interview question for any real-time feature.

The core limitation

HTTP is request–response: the browser sends a request, the server replies, and the connection closes. The server cannot initiate — it can't tap you on the shoulder to say "new message!" So every real-time approach is a workaround for that one restriction.

1. Short polling — just keep asking

The simplest idea: the client asks "anything new?" every few seconds on a timer. If there is, great; if not, the server says "nope."

Pro: trivial to build with plain HTTP. Con: wasteful and laggy. Most requests return nothing (wasted traffic and server load), and an update can sit up to one interval before you see it. Fine for something that changes slowly and doesn't need to be instant.

2. Long polling — ask, but wait

🟠 A smarter twist: the client asks, and the server holds the request open until it actually has something to send (or a timeout). The moment there's news, the server responds; the client immediately opens another request. It feels near-real-time using ordinary HTTP.

Pro: works everywhere, near-instant updates, far less wasted chatter than short polling. Con: still a new connection per message, and holding many open requests strains the server. It was the workhorse before better options existed — and it's still a solid fallback.

3. Server-Sent Events (SSE) — a one-way stream

🟠 SSE opens a single long-lived HTTP connection down which the server streams updates whenever it likes. One connection, many messages, one direction (server → client). The browser's EventSource even auto-reconnects for you.

Great for: feeds that are push-only — live scores, notifications, a news ticker, streaming an AI response token by token. Limit: it's one-way. The client can't send data back over the same channel (it uses a normal request for that). Simple and efficient when you only need the server to talk.

4. WebSockets — a two-way pipe

🟠 WebSockets upgrade a single connection into a persistent, full-duplex channel: both sides can send messages any time, instantly, over the same open socket. It starts as HTTP, then "upgrades" to the WebSocket protocol and stays open.

Great for: truly interactive, two-way, low-latency apps — chat, multiplayer games, collaborative editing (Google Docs), live trading. Cost: more complex — you manage connection state, reconnection, and scaling many persistent connections across servers (which needs sticky routing or a shared pub/sub layer). Powerful, but don't reach for it unless you genuinely need two-way real-time.

Side by side

How to choose (the senior answer)

• Updates rare / instant not needed? → short polling. Don't over-engineer.
• Server pushes to client only (notifications, live feed, scores, AI token stream)? → SSE. Simple, efficient, auto-reconnects.
• Both sides talk constantly, low latency (chat, games, collaboration)? → WebSockets.
• Need broad compatibility / a fallback where WebSockets are blocked? → long polling.

The senior instinct is to reach for the simplest tool that meets the need: don't open a WebSocket for a notification feed when SSE does it with less complexity.

The interview-ready summary

"Plain HTTP can't let the server push, so for real-time I choose based on direction and latency. Short polling for slow, non-urgent updates. SSE for one-way server→client streams like notifications or live feeds — one connection, auto-reconnect. WebSockets for two-way, low-latency interaction like chat or games — a persistent full-duplex socket, at the cost of managing connection state and scaling. Long polling is my compatible fallback. I'd pick the simplest option that fits, so I don't take on WebSocket complexity I don't need." That framing — direction, latency, simplicity — is exactly what interviewers want."

What to read next

• Design a Chat System — WebSockets applied end-to-end
• Message Queues & Kafka — the pub/sub layer that fans out messages to sockets
• API Design: REST, gRPC & GraphQL — the request/response world this extends
• ← The complete System Design guide (hub)

← ACID & isolation levels · Bloom filters →