Long Polling vs WebSockets

WebSockets named long polling as the workaround it replaced, and promised the full head-to-head here. Both solve the same problem — getting server-originated updates to a client faster than repeatedly asking "anything new?" — but they solve it with a fundamentally different relationship to plain HTTP request/response.

Long polling: stretching a request, not replacing it

Long polling is a clever trick that stays entirely within the ordinary HTTP request/response model: the client sends a request, and instead of answering immediately, the server holds the connection open without responding until it actually has something new to say (or a timeout is reached). The moment the client gets a response, it immediately opens a new request and the cycle repeats. From the client's perspective, this feels like the server is pushing — but structurally, it's still the client always initiating, just doing so in a way that minimizes the delay between "something happened" and "the client found out."

System Design Lab

WebSockets: leaving the request/response model entirely

WebSockets don't stretch a request — they upgrade one HTTP request into a genuinely different kind of connection, one that stays open indefinitely and lets either side send a message at any time, with no request needing to precede a server-originated message. This is a structurally different guarantee than long polling's repeated-request illusion: true full-duplex, not a clever reuse of request/response.

What long polling actually costs vs. what it saves

Long polling's overhead is real but easy to underestimate: every single message still requires a full new HTTP request — new headers, a new TCP handshake unless connections are being reused, and (if on HTTPS) the TLS handshake cost the first time a new connection is needed. For an update every few seconds, this is a meaningfully worse cost profile than a WebSocket's one-time connection setup amortized across every subsequent message. What long polling saves is exactly what WebSockets cost: no persistent connection to hold open server-side, no special infrastructure for Load Balancer sticky routing, and it works over plain HTTP that every proxy, firewall, and piece of existing infrastructure already understands without special-casing.

Why long polling is still the right choice sometimes

It's tempting to treat WebSockets as a strict upgrade, but that's not quite right — long polling remains the simpler, lower-risk choice when updates are genuinely infrequent (once every 30 seconds is a very different cost profile than once a second), when infrastructure compatibility matters more than marginal latency (some older proxies and load balancers handle plain HTTP more predictably than persistent WebSocket connections), or when the added operational complexity of stateful connections — sticky routing, cross-server broadcasting — isn't worth taking on for a feature that doesn't need sub-second updates.

Why this matters in an interview

The right answer depends entirely on update frequency and latency requirements, and naming that dependency explicitly is the strong move: "if updates are infrequent, long polling avoids the operational cost of stateful WebSocket connections; if they're frequent or need to be genuinely bidirectional, WebSockets amortize connection setup across many messages and avoid repeated HTTP overhead." Defaulting to WebSockets for everything "because it's more real-time" skips over a real cost-benefit call.