Polling vs push
Key takeaways Request/response has a blind spot: the server can never speak first. A client that needs to know about events can poll — ask on a schedule, paying with wasted requests and up to one interval of latency — or the system can push: keep a channel open (WebSockets, SSE) or call the client back (webhooks) so news travels the moment it exists. Long polling sits between. The choice is a trade of latency against cost and complexity, and it shapes everything in this unit.
A scanner is the perfect stage for this problem: calls start at unpredictable moments, and “tell me when talkgroup 1201 keys up” is the whole product. This lesson frames the polling-versus-push trade that the next four lessons — WebSockets, server-sent events, webhooks, and backpressure — each resolve differently.
The problem: news the client doesn’t know to ask for
Everything in Unit 2 was client-initiated: no request, no response. But events — a call starting, a system going quiet, a config change — happen on the server’s clock. In pure request/response, the freshest a client can be is as fresh as its last question. So the client asks repeatedly:
# crontab-grade "real-time": ask every 5 seconds
while true; do
curl -s http://scanner.local:8080/api/v1/calls?limit=1
sleep 5
done
That’s polling, and it genuinely works — it’s the simplest thing that can possibly function, built from nothing but GETs. Its two costs are structural:
- Latency. A call starting right after a poll waits a full interval to be noticed. Average delay: half the interval.
- Waste. On a quiet system, hundreds of requests an hour return “nothing new” — load on the server, noise in the logs, battery on mobile clients — and the server pays that cost multiplied by every polling client it has.
Tightening the interval trades one cost for the other. Polling at 100 ms is low-latency and abusive; polling hourly is polite and stale. There is no interval that’s both.
Push: let the server speak
Push inverts the flow: when the event happens, the server initiates delivery. The catch is that “the server initiates” isn’t something bare request/response can express, so every push mechanism is a workaround with its own shape:
| Mechanism | How the server gets a voice | Lesson |
|---|---|---|
| Long polling | Client asks; server withholds the answer until there’s news | (below) |
| Server-sent events | Client opens a response the server never finishes, streaming events into it | SSE |
| WebSockets | One handshake upgrades the connection to a permanent two-way pipe | WebSockets |
| Webhooks | The server becomes a client of you — it POSTs to your URL | Webhooks |
Note what they share: someone is now maintaining state between requests — an open connection, or a registered callback URL. That’s the price of push, and it’s why polling never fully dies: stateless, cache-friendly, firewall-proof asking is sometimes worth the staleness.
Long polling: the clever compromise
Long polling deserves its own moment because it delivers push-like latency with only HTTP: the client asks “anything new?”, and the server simply doesn’t answer until there is something (or ~30 s passes) — then the client re-asks immediately. News flows within milliseconds of happening, yet every hop is an ordinary request/response. The cost lands on the server, which now holds many open, idle requests. It was the web’s main real-time trick before WebSockets and still shines where proxies or old infrastructure choke on fancier transports.
Choosing, in practice
Rule of thumb: poll when staleness is cheap (a dashboard refreshing a daily stat), push when moments matter (a call notification), and prefer the simplest push that fits — SSE before WebSockets if the flow is one-way.
And a preview of the unit’s hardest lesson: push creates a new failure mode. When the producer can emit events faster than a consumer drains them, something must buffer, block, or drop — that’s streaming & backpressure, and no push system escapes it.
Quick check: a client polls every 10 seconds. On average, how stale is its knowledge of a new event?
Recap
- Request/response means the server can never speak first — the structural gap all real-time techniques fill.
- Polling is simple and stateless but trades latency (≈ half the interval) against waste, with no interval that fixes both.
- Push delivers events the moment they happen, at the price of state between requests — an open connection or a registered callback.
- Long polling fakes push over plain HTTP by withholding the answer until there’s news.
- Choose the simplest mechanism that meets the latency need — and remember every push system inherits the backpressure problem.
Next up: WebSockets.
Frequently asked questions
What is polling in an API?
Polling is when a client repeatedly asks the server whether anything has changed — for example, requesting the latest call log every few seconds. It works with nothing but plain request/response HTTP, which is its great strength, but it wastes requests when nothing is happening and adds delay (up to one full polling interval) when something is.
What is the difference between polling and webhooks?
With polling, your program asks the server for news on a schedule. With a webhook, the roles reverse — the server sends an HTTP request to your endpoint the moment an event happens. Webhooks eliminate the constant asking, but require you to run something that can receive requests, which is a real operational cost.
What is long polling?
Long polling is a hybrid: the client asks, and the server holds the request open — not answering — until it actually has news (or a timeout passes). The client then immediately asks again. It delivers near-push latency using only ordinary HTTP, at the cost of the server juggling many open, idle requests.