Skip to main content

WebSockets

Every API pattern covered so far in this module shares one assumption: the client asks, the server answers, and the connection's job is done. WebSockets break that assumption on purpose — they establish a single, long-lived connection over which either side can send a message to the other, at any time, without the other side having asked first. That's the difference between an ordering system where you have to keep asking "is it ready yet?" and one where the kitchen taps you on the shoulder the moment it is.

From HTTP request to persistent connection​

A WebSocket connection starts as an ordinary HTTP request — the client sends a GET with an Upgrade: websocket header — and if the server agrees, that same underlying TCP connection is repurposed to carry WebSocket frames instead of further HTTP requests. It's worth being precise about this in an interview: WebSockets don't replace HTTP, they piggyback on one HTTP request to bootstrap a connection that then leaves the request/response model entirely, running over raw TCP for as long as it stays open.

System Design Lab

Once that handshake completes, both sides can push messages independently — this is what "full-duplex" means: unlike a single HTTP request/response pair, there's no fixed turn-taking, and the server doesn't need the client to ask again to send new data.

Why not just poll?​

Before WebSockets, "real-time" updates over HTTP meant one of two workarounds, both of which exist specifically because plain HTTP can't push:

  • Short polling — the client repeatedly sends a request every N seconds asking "anything new?" Simple, but wasteful (most polls return nothing) and never faster than the polling interval.
  • Long polling — the client sends a request and the server holds it open until there's something to say, then responds; the client immediately opens a new one. Better latency than short polling, but still pays a new HTTP request's overhead for every single message, and still isn't full-duplex.

A WebSocket connection amortizes the handshake cost across the entire connection's lifetime instead of paying it per message, and lets the server push without the client asking — the direct fix for both of polling's problems at once. The full head-to-head on when long polling is still the simpler, better choice gets its own lesson: Long Polling vs. WebSockets.

The tradeoff: statefulness​

A plain HTTP API is stateless by design — see HTTP/HTTPS — which is exactly what makes it trivial to route any request to any server behind a load balancer. A WebSocket connection breaks that: once a client is connected to a specific server, it's pinned there for the life of the connection, because the connection is the state. This has real consequences for scaling:

  • Load balancing gets harder. New connections can still be distributed, but an established connection can't just be moved to a different server; the load balancer needs sticky routing (or the connection has to be dropped and re-established elsewhere).
  • Broadcasting requires coordination. If a message needs to reach every client subscribed to some event, and those clients are spread across many servers, the servers need a shared way to fan that message out — typically a pub/sub layer sitting behind the WebSocket servers, so any server can publish a message that reaches clients connected to any other server.
  • A dead connection needs active detection. Unlike a request that simply completes, a WebSocket connection can go silently stale (a client's laptop sleeps, a mobile network drops) without either side being notified — servers typically send periodic ping/pong frames, conceptually the same health-check idea as a load balancer detecting a dead backend, just running in the other direction.

This is really the same stateless vs. stateful tradeoff covered generally in Stateful vs. Stateless Design — WebSockets are the concrete case where a design deliberately gives up statelessness in exchange for capabilities plain HTTP can't offer.

Where WebSockets earn their complexity​

Chat applications, live collaborative editing, multiplayer games, and live dashboards (stock tickers, live sports scores) are the standard examples — all cases where updates need to reach the client with low latency, arrive frequently, and can originate from the server with no client request to trigger them. If updates are infrequent, latency-tolerant, or always client-initiated, the added operational complexity of stateful connections usually isn't worth it, and plain HTTP (or long polling) is the simpler, better-supported choice.

Choosing WebSockets over HTTP polling: pros and cons​

Pros

  • Server can push data the instant it's available — no polling delay
  • One persistent connection instead of a new HTTP request per update
  • True full-duplex — both sides send independently, at any time

Cons

  • Connections are stateful — pins a client to a specific server
  • Load balancing and cross-server broadcasting require extra coordination
  • Needs its own liveness detection; a dead connection doesn't announce itself

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.