WebSockets & Realtime

Chat, live notifications, collaborative editing, multiplayer games, trading dashboards — all need the server to push data to the client the instant something happens. Plain HTTP can't: it's request/response, always initiated by the client. WebSockets solve this with a persistent, full-duplex connection over which either side can send at any time. Understanding the options — polling, long-polling, SSE, and WebSockets — and how to scale stateful connections is the core of any real-time design, like our chat app.

The Problem: HTTP Is One-Way

HTTP's model is simple and scalable: a client sends a request, the server responds, done. But it means the server has no way to initiate — it can only answer. For anything where the server needs to tell the client "a new message arrived" or "the price changed," that's a fundamental mismatch. The naive workaround is polling (the client asks "anything new?" every few seconds), which is wasteful — mostly empty responses — and laggy. The history of real-time on the web is a series of increasingly better answers to this.

The Evolution: Polling → Long-Polling → SSE → WebSockets

• Short polling — client requests on a timer. Simple, but wastes requests and adds latency up to the poll interval.
• Long polling — the client requests and the server holds the request open until it has data (or a timeout), then the client immediately re-requests. Near-real-time, works everywhere, but it's a hack with connection churn and overhead.
• Server-Sent Events (SSE) — a standardized one-way stream: the server pushes a continuous event stream over a single long-lived HTTP response. Simple, auto-reconnects, but server→client only.
• WebSockets — a persistent, full-duplex connection where both sides push freely. The most capable, and the right tool when the client also needs to send frequently.

What WebSockets Are

A WebSocket is a single, long-lived TCP connection that supports full-duplex communication — both client and server can send messages at any time, independently, with low overhead per message (no HTTP headers per message). It begins life as an ordinary HTTP request so it works through existing web infrastructure, then upgrades: once established, it's a bare bidirectional message pipe (ws://, or wss:// over TLS).

# client → server (looks like HTTP)
GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

# server → client
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

# → connection is now a full-duplex WebSocket; either side sends anytime

WebSockets vs SSE vs Long-Polling

The decision rule: if the client only needs to receive updates, SSE is simpler and rides on plain HTTP. If the client also sends frequently (typing in a chat, moving in a game), use WebSockets. Long-polling is the universal fallback when neither is available.

Scaling WebSockets: the Real Challenge

Anyone can open a WebSocket; the hard part is operating millions of them. Unlike stateless HTTP requests that any server can handle, a WebSocket is a stateful, long-lived connection pinned to one specific server. That creates several problems:

• Many idle connections — a chat service may hold millions of mostly-idle sockets; each consumes memory and a file descriptor, so connection density per server matters.
• Sticky routing — the load balancer must keep a client pinned to the server holding its connection (and must support the WebSocket upgrade in the first place — see load balancing).
• The fan-out problem — the killer issue, below.

The Fan-Out Problem and the Backplane

Suppose Alice and Bob are in the same chat room but their WebSockets are connected to different servers. When Alice sends a message, the server holding her connection has no direct way to reach Bob's connection on another server. The solution is a pub/sub backplane: servers publish incoming messages to a shared bus (commonly Redis pub/sub or Kafka), and every server subscribed to that room receives the message and pushes it down to its own connected clients.

Alice ──ws──▶ WS-server-1 ──publish "room42"──▶ ┌───────────────┐
                                                │ Redis pub/sub │
Bob   ──ws──▶ WS-server-2 ◀──subscribe "room42"─┤  (backplane)  │
                  │                             └───────────────┘
                  └──push──▶ Bob   (server-2 delivers to its own client)

  every WS server subscribes to the rooms its clients are in;
  the backplane bridges connections that live on different servers

This backplane is the defining piece of WebSocket scaling — without it, horizontal scaling breaks because messages can't cross server boundaries.

Heartbeats and Reconnection

Long-lived connections die silently — a laptop sleeps, a network blips, a proxy times out an idle connection — often without a clean close. Two mechanisms keep things healthy. Heartbeats (WebSocket ping/pong frames at intervals) detect dead connections so the server can reclaim resources and the client knows to reconnect. Reconnection logic on the client re-establishes the socket after a drop, ideally with exponential backoff (to avoid a thundering herd when a server restarts) and a way to resume — replaying missed messages since the last received ID so nothing is lost across the gap.

Use Cases

• Chat & messaging — the canonical bidirectional case (see chat app design).
• Live notifications & presence — "user is typing," online status, alerts (SSE often suffices if one-way).
• Collaborative editing — shared cursors and edits (Google Docs-style), needing low-latency two-way sync.
• Live dashboards, gaming, trading — continuous, latency-sensitive updates in both directions.

Pitfalls

• Infrastructure support — load balancers, proxies, and gateways must explicitly support the WebSocket upgrade and long-lived connections.
• Connection limits — OS file-descriptor and memory limits cap connections per server; tune and plan capacity for idle sockets.
• No backplane — forgetting the pub/sub layer means messages can't reach clients on other servers; the classic scaling miss.
• State on the connection — pinning users to servers complicates deploys (draining connections on restart) and failover.
• Overkill — if updates are infrequent or one-way, SSE or even polling is simpler and cheaper than a full WebSocket stack.