Long Polling
Long polling holds an HTTP request open until an update or timeout arrives, giving near-real-time delivery without WebSockets or dedicated streaming protocols.
Definition
Long polling is a technique where the client sends a request that the server deliberately delays, responding only when data is available or a timeout elapses, and the client immediately reconnects after each response.
Context and scope
Use it as a compatibility fallback when SSE or WebSockets are blocked by proxies, or for low-frequency events where streaming infrastructure is overkill.
Common misconceptions
- Long polling keeps one permanent connection open; each poll ends and must be reopened
- It is identical to streaming; every response restarts the request cycle
- A timeout is an error; it is the normal signal to reconnect
Anti-patterns
- Holding requests indefinitely without a server timeout, exhausting worker slots
- Reconnecting in a tight loop without backoff after failures
- Resending the full dataset on every poll instead of a cursor delta
Related concepts
Related examples
Authoritative source
How it works
The client asks for events with a cursor or timestamp. If the server has nothing new, it does not answer immediately; it parks the request until an event arrives or a timeout fires. When the response finally comes back — with data or with an empty timeout result — the client opens a new request using the latest cursor.
let cursor = 0;
while (running) {
const res = await fetch(`/events?since=${cursor}`, { signal });
const events = await res.json();
for (const event of events) {
cursor = Math.max(cursor, event.id);
handle(event);
}
}The loop looks like polling, but each iteration waits on the server. That reduces empty round trips compared with fixed-interval polling, while staying inside plain HTTP: no upgrade handshake, no special proxy support.
When to use it
Long polling is a pragmatic choice when older proxies, corporate firewalls, or restricted runtimes block WebSockets and SSE, or when updates are infrequent enough that a streaming connection is unnecessary. It also works in environments where only request/response APIs are available.
Trade-offs
Every waiting client occupies a server connection and often a worker or thread. With many clients, the cost approaches holding open one connection each anyway, without the efficiency of a real stream. A timeout creates a burst of reconnects, so jitter and backoff matter. Events that occur between the response and the next request can be missed unless the cursor is durable.
Example and misconceptions
The classic mistake is treating long polling as a permanent subscription. It is a repeated request/response loop with a deliberate delay, which is why missed-event handling and cursor design determine correctness.
Related concepts: Server-Sent Events, Timeout Budget, and Backpressure.