Long polling
A fallback realtime technique where the client requests an update and the server holds the request open until data is ready or a timeout, then responds; the client immediately re-polls. It simulates push over plain HTTP.
- Legacy clients or networks blocking WS/SSE.
- Infrequent events where simplicity beats infra.
- New apps that can use WebSockets or SSE.
- High-frequency updates (too much overhead).
Definition
Client sends a request; instead of responding immediately, the server waits (up to a timeout) for an event, then returns. The client processes and opens a new request. It's polling where each 'poll' may last minutes.
Why it exists
Before WebSockets/SSE, this was the only way to get near-realtime push through any HTTP stack. Still useful where WebSockets/SSE are blocked or for trivial cases.
How it works
Server holds the request, checking a queue/condition with a timeout. On event or timeout, it responds. Latency is one round trip per event; overhead is a connection per pending request. Often combined with backoff.
Scaling limits
Each pending request holds a server connection/thread; many clients need async I/O (epoll) not thread-per-request. Connection churn is high.
Cost shape
High connection overhead vs WebSockets/SSE. Cheap to implement; expensive to scale.
Alternatives
- SSE — Cleaner one-way push with auto-reconnect.
- WebSockets — Bidirectional and lower overhead for frequent traffic.
Failure modes
- Thread-per-request servers exhausting threads.
- Reconnect storms after a widespread timeout.