Long Polling

Overview

Long polling is an HTTP technique where the server delays its response until it has something to say. The client re-requests right after each reply, creating a loop that feels like push while using ordinary requests.

How it works

The client keeps a cursor representing the last event it processed.

loop:
  GET /events?after=105&wait=30
  server: if events after 105 exist -> return them now
          else park request up to 30s
          on new event -> return it
          on timeout   -> return 204 empty
  client: update cursor, repeat immediately

The cursor is essential: events that occur between a response and the next request are returned immediately on the next call. The server parks requests in an event loop or async handler and wakes them through an in-memory registry or pub/sub channel. Hold time should sit safely below load balancer idle timeouts, for example 30 seconds against a 60 second limit.

Pitfalls

• Missing cursor. Without it, any event in the reconnect gap vanishes.
• Blocking threads. Use async I/O or waiting clients will exhaust the thread pool.
• Hot loops on errors. Apply exponential backoff with jitter when requests fail.
• Wake-all stampedes. Wake only the waiters interested in the changed topic.
• Using it for streams of many events per second; the per-request overhead dominates.

Key takeaways

• Hold the request until data or timeout, then re-request with a cursor.
• Keep hold time under proxy idle limits.
• Use async servers and targeted wake-ups.
• Prefer SSE or WebSockets where available; keep long polling as a fallback.