Topic 6.8
Long Polling
In one line
The HTTP-compatible trick for push-ish: hold the response open until there's news or a timeout.
Think of it like this
Asking a friend 'text me the moment the movie tickets go on sale' and they keep the phone line open, saying nothing until it actually happens, then hang up so you call them again to keep watching.
Key ideas
- 01
Client requests; server HOLDS the connection until data exists (or ~30s timeout) then responds; client re-requests immediately.
- 02
Reduces empty polls vs short polling; still one request per event plus latency on timeout.
- 03
Same request semantics as normal HTTP — works through firewalls/proxies/LB without special support.
- 04
Costs: a held-open connection is a thread/resource on the server (async IO helps); timeout must be coordinated LB ↔ server.
- 05
Ranking for realtime-ish: WebSocket > SSE > long-polling > short polling (in that order of modernity).
- 06
Interview: legacy browsers/proxies → long-polling is your safe fallback for chat.
Java / Spring map
- →
Spring: DeferredResult / WebAsyncTask for async long-poll; or CompletableFuture responses.
Code & diagrams
The difference is entirely in how long the server waits before answering.
Explain without notes
Why is long-polling 'one connection per user' expensive at 1M users?
Practice
Sketch chat-with-long-polling: inbound message storage, the waiter thread, and the re-poll loop.
Trade-offs
- ↔
Simplicity vs connection churn; every timeout fires a NEW request and re-establishes state.
Completion checklist
I can place long-polling on the realtime ladder and justify its slot.