skip to content

In short polling, how does the client's fixed interval trade worst-case staleness against the cost of empty polls?

level: middleimportance: should knowfreq 62%

answer

  1. interval is your staleness budget
  2. requests scale as clients over interval
  3. change rate is absent from that formula
  4. fields dwarf an empty body
  5. halve the interval, double the bill

basics

~20 s

The interval is the staleness budget: an update can wait almost a full interval plus a round trip. Halving it halves that wait and doubles request volume, and on a rarely-changing feed nearly every extra request returns nothing.

solid answer

~40 s

Two numbers move together. Worst-case staleness is one interval plus a round trip; mean staleness is about half an interval. Request volume is `clients / interval`, so the rate is fixed by the fleet, not by how often anything happens. The trap is treating an empty poll as free because the body is empty: each one still carries a request line, the client's whole field set, a status line and response fields, and on a metered or battery-powered link it also costs a radio wake. On a feed that changes twice an hour, a 10-second interval means about 0.6% of exchanges carry news and the rest are pure overhead. Before shrinking the interval, price the volume it creates; before widening it, check the staleness against what the consumer actually needs.

code

http · 13 lines
http
GET /pivot/42/events?since=1733 HTTP/1.1
Host: fleet.example.net
Accept: application/json
Authorization: Bearer <token>
User-Agent: pivot-controller/3.1 (imei 35xxxxxxxxxx)

HTTP/1.1 200 OK
Date: Thu, 18 Sep 2026 09:31:04 GMT
Content-Type: application/json
Cache-Control: no-store
Content-Length: 25

{"events":[],"next":1733}

go deeper

for a junior

Remember that the interval is the worst-case wait, and that a poll returning nothing still costs a full request and response.

for a middle

Be able to write the two formulas on the spot — worst-case staleness of one interval plus a round trip, and a request rate of clients divided by interval — and explain why the change rate does not appear in the second.

for a senior

Show the fleet arithmetic and its consequences: a rate fixed by the fleet size, most of it empty, and the link, radio and server cost that follows from the number someone picked once.

for a principal

Own the interval as a budget decision across consumers with different freshness needs, rather than giving every device the tightest requirement anyone in the system has.

Short polling has exactly one tuning knob, and it sets two things at once. Understanding which two is most of the question. ## What the interval actually controls The interval is a **staleness budget**, not a latency figure. - **Worst case**: an update published the instant after the server handled a poll waits the whole interval, plus a round trip, before it is seen. - **Mean**: averaged over arrival times, about half an interval plus a round trip. - **Floor**: no interval takes staleness below one round trip, so shrinking an interval below the network's own latency buys nothing but requests. It also fixes the request rate: `requests per second = clients / interval`. Note what is missing from that expression — how often the data changes. A short-polling fleet sends the same volume on a quiet day as on a busy one. ## What one empty poll costs An empty answer is not a cheap answer. - The request carries a request line, a target, and the client's whole field set — host, accepted media type, credentials, and whatever else the client always sends. - The response carries a status line and its own fields, of which the body may be a dozen bytes saying there is nothing. - On a cold path the exchange also pays for setting up a connection before any of that. - On a metered cellular link or a battery-powered device, the exchange wakes a radio, which costs far more than the bytes suggest. A request-plus-response whose field sets total on the order of 600 bytes will move several megabytes per device per day on a tight interval while carrying almost nothing. ## The arithmetic at fleet scale Take 5,000 field controllers with something to report twice an hour — 48 updates per device per day. | interval | worst-case staleness | requests per device per day | fleet requests per day | polls carrying news | |---|---|---|---|---| | 1 s | ~1 s | 86,400 | 432 million | 0.06% | | 10 s | ~10 s | 8,640 | 43.2 million | 0.6% | | 60 s | ~60 s | 1,440 | 7.2 million | 3.3% | | 15 min | ~15 min | 96 | 480,000 | 50% | At 10 seconds, the fleet sends about 500 requests a second forever, and at roughly 600 bytes an exchange that is on the order of 26 GB a day of link traffic to deliver 240,000 actual updates. At 60 seconds the traffic falls sixfold for the price of up to a minute of staleness. The table is the conversation to have with whoever specified the interval: nobody chooses 432 million requests a day on purpose, but plenty of systems arrive there by picking a number that felt responsive. ## Where the trade stops being linear Two effects bend the curve: 1. **Below the round trip**, shrinking the interval adds requests without improving what the consumer sees, because the exchange itself now dominates. 2. **Above the change rate**, widening the interval stops saving anything useful: once most polls carry news, you are paying one exchange per update, which is the floor any technique pays. Between those bounds the trade is roughly linear and entirely yours to set. ## What to do instead of shrinking the interval - **Batch.** Answer with everything published since the position the client supplied, so one response can clear a burst rather than forcing a poll per event. - **Trim the request.** On a link where the field set dwarfs the body, removing what the client does not need to send is a real saving multiplied by the poll rate. - **Align the interval to the device.** A controller that wakes on its own schedule should poll on wake; polling faster than it wakes is spending the radio for nothing. - **Separate the two consumers.** Whoever needs sub-second freshness and whoever needs a daily roll-up do not need the same interval; do not give the whole fleet the tightest requirement anyone has. - **Consider holding the request instead.** Long polling replaces `clients / interval` with `clients / hold period` for the idle case while getting news out about a round trip after it happens — at the cost of parked server state per client.

  • At what event rate does long polling stop being cheaper than short polling?
    Once events arrive faster than the hold period would have expired, every publish costs its own request/response cycle plus the gap that follows it. At that point long polling has degenerated to an exchange per event, and a short poll on a sensible interval that batches everything since the client's position clears the same events in fewer round trips.
  • How do you cut polling cost without touching the interval?
    Batch the answer so one response clears every event since the client's position; trim the request field set, which is multiplied by the poll rate; and align the poll to the device's own wake schedule so it never spends a radio wake on a poll nobody was waiting for.

saying these in an interview costs you the question

  • Treats the poll interval as average latency rather than the worst case
  • Assumes an empty response is nearly free because the body is empty
  • Shrinks the interval to chase freshness without pricing the request volume
  • Thinks a tighter interval can take staleness below one round trip
  • Budgets a metered link on payload bytes and ignores the field sets
  • Believes request volume falls when the data changes less often