Long Polling

With normal HTTP, the client asks and the server answers right away. If the client wants to know about new data, it has to keep asking. Plain polling means asking every few seconds on a fixed timer, which wastes requests when nothing has changed and adds delay when something does change between polls.

Long polling flips the waiting. The client makes a request, and instead of answering immediately, the server holds the request open. It only sends a response when there is actually something new to deliver, or when a timeout (commonly 20 to 60 seconds) is reached. As soon as the client gets a response, it fires off a fresh request and the cycle repeats.

The result feels close to real time. When an event happens on the server, the response that was being held gets flushed back to the client within milliseconds, instead of waiting for the next fixed poll interval. From the browser's point of view it is still just regular HTTP request and response, so it works through old proxies, firewalls, and load balancers that do not understand newer protocols.

The client opens a request to an endpoint, for example GET /updates?since=12345. On the server, the handler does not return a response immediately. It registers a listener or blocks on a condition, waiting for an event that concerns this client, such as a new chat message or a changed order status.

Three things can end the wait. New data arrives and the server writes it into the held response and closes it. The timeout fires and the server returns an empty or no-change response so the connection does not stay open forever. Or the connection drops, in which case the client notices and reconnects.

Because each held request ties up a connection and often a server thread or async task for its whole lifetime, long polling demands a server that can keep many idle connections cheap. Synchronous, thread-per-request servers fall over fast here. Event-driven runtimes like Node.js, Go, or Java with NIO handle thousands of parked connections because a waiting request consumes almost no CPU. The client usually passes a cursor like a last-seen ID or timestamp so the server knows exactly what the client already has and can avoid sending duplicates or missing events during the brief gap between one response closing and the next request opening.

Long polling earns its place when you need server-to-client updates but cannot rely on WebSockets. That happens behind strict corporate proxies that block the WebSocket upgrade, on legacy browsers, or when your infrastructure (some CDNs, older load balancers) handles plain HTTP much more reliably than long-lived socket connections. It is also simpler to reason about because every exchange is a standard request and response that you can cache, log, and debug with normal HTTP tools.

The cost is overhead. Every cycle pays for a full HTTP request and response, including headers, and a new connection setup if keep-alive is not in play. Under high message rates the client spends most of its time reconnecting, which is wasteful compared to a single persistent WebSocket. Latency also has a floor: there is a small gap between one response closing and the next request opening, and any event landing in that gap waits for the next cycle.

For genuinely high-frequency, two-way, low-latency traffic such as multiplayer games, collaborative editors, or live trading, WebSockets are the better fit. For one-way streams of updates like notifications or a live feed, Server-Sent Events are simpler. Long polling is the pragmatic middle ground: more real-time than fixed-interval polling, more compatible than WebSockets, and good enough for moderate update rates.

Picture a chat app. A user has a conversation open and the browser sends GET /messages?roomId=42&after=998. The server has no new messages, so it parks the request and waits.

Thirty seconds later someone posts. The server's message handler wakes the parked request, writes the new message as JSON, and closes the response. The browser receives it in roughly the time it takes the message to travel the network, renders it, and instantly sends GET /messages?roomId=42&after=999 to wait for the next one.

If nobody posts for 30 seconds, the server returns an empty 204 or an empty array so the request does not hang indefinitely, and the browser reconnects. Facebook Chat ran exactly this pattern for years before WebSockets were standard, and many systems still keep long polling as the automatic fallback when a WebSocket connection cannot be established.