WebSockets and Long Polling

HTTP was designed around a request-response model: the client asks, the server answers, the connection is done. That model breaks down for chat apps, live dashboards, multiplayer games, and stock tickers, where the server needs to push data the instant it becomes available. Over the years, three broad strategies emerged to bridge this gap: short polling, long polling, and WebSockets, each trading off latency, server load, and implementation complexity differently. The simplest of the three, short polling, has the client send a request every N seconds asking 'anything new?', with the server replying immediately whether or not there's anything to report; it's trivial to implement and works through any proxy or firewall, but it wastes enormous bandwidth and server capacity on empty responses, and the polling interval directly bounds latency — halve the interval and you double the request volume for marginally fresher data. It's rarely acceptable for anything beyond low-frequency status checks, which is why long polling and WebSockets exist. Understanding when to reach for each is a recurring system design decision, especially for any 'real-time feature' requirement.

Long polling improves on this by having the server hold the request open — not responding immediately — until new data is available or a timeout (typically 20-60 seconds) elapses. The moment data arrives, the server responds and closes the connection; the client immediately reopens a new request. This collapses the latency-vs-request-volume tradeoff of short polling: updates arrive close to instantly, and idle periods generate far fewer requests. The cost is that each held-open connection consumes a server thread or event-loop slot for a long time, and you still pay full HTTP header overhead on every reconnect cycle.

WebSockets solve the underlying problem directly: after an HTTP handshake (the Upgrade header) the TCP connection is repurposed into a persistent, full-duplex channel where either side can send frames at any time with minimal per-message overhead. There's no repeated reconnect, no wasted headers, and true bidirectional push — the server can send unprompted, and the client can send without waiting for a response. This makes WebSockets the natural choice for chat, collaborative editing, live multiplayer state, and trading platforms. The cost is operational: connections are long-lived and stateful, so load balancers need sticky routing or a shared pub-sub backplane, connection counts become a capacity dimension in their own right, and reconnect/backoff logic must be handled explicitly on flaky networks.