WebSockets

What are WebSockets?

WebSockets provide a persistent, full-duplex (two-way) communication channel between a client (typically a browser) and a server over a single long-lived connection. Once established, both sides can send messages to each other at any time, instantly, without the overhead of opening a new HTTP request for each exchange. This is fundamentally different from the classic HTTP request/response model, where the client asks and the server answers and the connection’s usefulness ends there. WebSockets are the standard technology behind real-time web features: chat, live collaboration, multiplayer games, live dashboards, and trading/streaming interfaces.

Why they exist — the limits of HTTP request/response

Standard HTTP is client-initiated and one-shot: the client sends a request, the server responds, done. That’s fine for loading pages and calling APIs, but it’s a poor fit when the server needs to push data to the client as things happen, because the server has no way to initiate contact. The old workarounds were ugly: short polling (the client asks “anything new?” over and over — wasteful and laggy) and long polling (the client’s request is held open until there’s data — better, but still request-per-message overhead). WebSockets solve this properly: after an initial HTTP handshake that upgrades the connection (the Upgrade: websocket header) to the WebSocket protocol, the connection stays open and either side can send messages freely with minimal per-message overhead. That’s the defining capability — true bidirectional, low-latency, low-overhead messaging — which is exactly what real-time collaborative and interactive apps need and what request/response can’t deliver cleanly.

WebSockets vs SSE — and the operational realities

The most important design decision is WebSockets vs Server-Sent Events (SSE), and the honest guidance is to use the simpler tool that fits. If you only need server→client streaming (notifications, live feeds, progress updates, streaming LLM token output), SSE is simpler: it runs over plain HTTP, auto-reconnects in the browser for free, and needs no protocol upgrade. Reach for WebSockets when you genuinely need client→server messages too — chat where the user types, collaborative editing, multiplayer input, anything where the client continuously sends as well as receives. Choosing WebSockets by reflex for one-directional data is the most common mismatch. On the operational side, WebSockets bring real complexity that request/response avoids: connections are stateful and long-lived, which complicates scaling and load balancing (a stateless HTTP load balancer model doesn’t map cleanly — you need sticky sessions or a shared pub/sub backplane like Redis so a message can reach whichever server holds a given client’s connection); you must handle reconnection yourself (WebSockets, unlike SSE, don’t auto-reconnect — clients need reconnect-with-backoff logic and often message replay after a drop); proxies, firewalls, and load balancers must be configured to allow and correctly handle the upgraded, long-lived connection; and each open connection consumes server resources, so connection count becomes a capacity concern at scale. Security matters too — use wss:// (WebSocket over TLS), validate the Origin header (WebSockets aren’t subject to the same-origin policy, so cross-site connection abuse is a real risk), and authenticate the connection.

What people get wrong

• Using WebSockets for one-way data — if only the server pushes, SSE is simpler and auto-reconnects; WebSockets earn their complexity only when the client also sends.
• Ignoring stateful scaling: long-lived connections break the stateless load-balancer model — you need sticky sessions or a pub/sub backplane to route messages across servers.
• Assuming auto-reconnect — unlike SSE, WebSockets don’t reconnect themselves; clients need reconnect/backoff and message-replay logic, or dropped connections silently lose data.

Primary source: MDN: The WebSocket API