Module 6 · Lesson 1 of 4
Polling and long polling
The simplest way to get updates, and what it costs.
Gatepass's seat map shows every seat in the hall, and a seat should turn grey on every phone the moment someone else books it. Right now each phone asks the server “anything new?” once a second. During a big on-sale, almost all of Gatepass's traffic is that one question, and almost every answer is “no”.
The question every phone keeps asking
The simplest way to get updates is to ask for them. The app calls the same endpoint on a timer, and the server answers with whatever is current. This is short polling.
Notice the since=1832. The phone sends the version of the seat map it already has, so the server can reply with only the changes (or with nothing at all). Without a version cursor, every poll would download all 400 seats again.
Polling has real strengths. It is plain HTTP, so it passes through every proxy, firewall and CDN. The server keeps no state about who is watching. If a server dies, the next poll goes to another one and nobody notices. It's the right default for many screens.
What short polling costs
Do the arithmetic for a big show. Ten thousand fans have the seat map open and each phone polls once a second. That's 10,000 requests a second, all reading the same seat map. Actual bookings during the same minute might be 50 a second. You built a system that spends 99.5% of its effort answering “no”.
The interval is a dial between two bad things:
- Poll often and you pay in requests. Halving the interval doubles the load.
- Poll rarely and the map goes stale. With a 10-second interval, a seat taken right after a poll stays green on screen for up to 10 seconds, about 5 seconds on average. Fans tap seats that are already gone and get an error at checkout.
You can make each poll cheaper. Cache the seat map for a second, answer 304 Not Modified when the version hasn't moved, keep the response tiny. Those tricks cut the cost per request, not the number of requests. The server still accepts 10,000 connections a second, parses 10,000 requests and runs 10,000 auth checks.
Short polling ties freshness to cost. You can't make it fresher without making it more expensive.
Long polling: let the server wait
What if the server didn't answer until it had something to say? With long polling, the phone sends the same request, but the server holds it open. When a seat changes, the server replies right away. If nothing happens for, say, 30 seconds, it replies “nothing new” and the phone asks again.
The phone learns about the change within one round trip instead of half an interval. And when nothing happens, a phone sends two requests a minute instead of sixty.
Long polling has its own catches, and they show up at exactly the wrong moment:
- Every held request is an open connection. Ten thousand phones means ten thousand requests sitting on your servers. A server that uses one thread per request runs out of threads long before it runs out of CPU. You need an event-loop server (Node, Go, async Python) that can park idle connections cheaply.
- Proxies hang up on quiet connections. Load balancers often close a connection with no traffic after 60 seconds. Keep the server's timeout well under the shortest idle timeout on the path.
- One change wakes everyone at once. When seat C14 sells, all 10,000 held requests complete in the same millisecond, and 10,000 new requests arrive a moment later. Long polling turns a steady trickle into synchronized waves.
- There's a gap between replies. After the reply and before the next request arrives, a change can happen with nobody listening. The
sincecursor covers this: the next request asks for everything after version 1833, so nothing is lost.
Try it: polling vs long polling vs push
Below is one phone's minute, drawn three ways, and what the server sees across every phone. Start with 10,000 phones, 6 seat changes a minute and a 2-second interval. Then push the interval to 10 seconds and watch staleness, and raise the seat changes to 60 a minute to see where long polling stops looking cheap.
Try it
How much does “any change?” cost?
One phone's minute on the seat map, three ways. Orange marks are seats being booked. Move the sliders and watch the server load below.
Seat changes
8 this minute
Short polling
30 requests, 23 empty
Long polling
10 requests, 2 timed out
Push (SSE / WebSocket)
1 connection, a message per change
Short polling
Requests / s
5.0k
Empty replies
82%
Avg. staleness
1.0 s
Long polling
Requests / s
1.1k
Empty replies
5%
Held open
10k
requests waiting
Push
Requests / s
0
after connecting
Messages / s
1.0k
Open connections
10k
A few things to notice:
- Short polling's request rate depends only on phones and interval. The amount of news makes no difference.
- Long polling's request rate rises with the update rate. At one change a second, it's as busy as short polling with a 1-second interval, plus the cost of holding every request open.
- Push sends exactly one message per change per phone and receives no requests at all. That's the next lesson.
When polling is the right answer
Polling is not a beginner's mistake. It is the right tool when updates are rare, a few seconds of staleness is fine, or the client only cares for a short time.
| Gatepass screen | Choice | Why |
|---|---|---|
| Payment status after checkout | Short poll every 2 s, for 60 s | Short-lived, one user, simple |
| “My tickets” page | Fetch on open, no polling | Changes only when the user acts |
| Event list for a city | Short poll every 60 s | Changes slowly, cacheable on a CDN |
| Seat map during an on-sale | Push | Many viewers, many changes, seconds matter |
Check yourself
Gatepass short-polls the seat map every 4 seconds. On average, how long after a seat is booked does a viewer see it turn grey?
Your turn
Gatepass wants a live “tickets left” counter on each event page: 30,000 people view the page during an on-sale, and the count changes about 20 times a second. List what you'd consider before choosing short polling, long polling or push.
Stuck? Think about how stale the number can be, how many viewers there are, and whether every change matters.
Key takeaways
- Short polling is simple and stateless, but freshness and cost are tied: halve the interval, double the requests.
- Average staleness under short polling is half the poll interval.
- Long polling replies the moment something changes, but holds a connection per viewer and turns each change into a wave of reconnects.
- Always poll with a version cursor so the server returns only what changed and nothing is missed between requests.
- Polling is the right choice for rare updates, short-lived waits and data you can cache. The live seat map needs push.
Finished reading?
Mark it complete to tick it off in the course.