Polling is simple, but it lags and wastes work
Aliases: polling · timed pull · pull interval · empty poll
What it is
Polling asks the server on a fixed or backing-off interval whether anything is new. Implementation is almost just a timer plus a request; no long-lived connection is required. The cost sits on the time ledger: a new fact waits on average half an interval to be seen, and most asks come back empty. It fits reads where change is slow, a few seconds of staleness is fine, and the connection is unreliable.
Why it happens
The client holds the clock; the server is passive. An event that falls between two asks is discovered with expected delay of half the interval; the worst case is “it happened just after we asked”, a full slot more. Compressing delay means asking more often, so the fraction of empty requests rises — change did not get denser, the asker got busier. That is the waste: bandwidth, battery, and server QPS spent confirming “still the old thing”.
Backoff (stretch the interval on error or no change) cuts waste, but delay gets worse during quiet spells; acting at the end of a quiet spell hits “why is this still old”. Several tabs each polling a copy multiply the waste by tab count; the server sees duplicate heartbeats from the same person.
Where it stops holding
Content that changes almost every second (a ticker, match state) forces polling toward a near-open short interval. Simplicity remains; waste already resembles a clumsy long connection, and the channel should change. After a write that must be read back immediately, half-interval delay looks like “it didn’t land”; admit it locally rather than shrinking the interval toward zero. Background tabs, lock screen, and low-power modes defer or coalesce timers, so the wall interval is no longer the real one and delay is worse than designed. If the server does a full recompute on every ask, waste becomes empty compute; a longer interval is still expensive.
Applying it
- Use polling for lists, badges, and non-conversation state whose change is measured in minutes and whose staleness of a few seconds is acceptable. Do not use it for “the other person is typing” or match frames.
- Publish a visible delay budget: half the interval is the freshness people will typically wait for. Do not treat the interval itself as freshness.
- Stretch the interval when nothing changes; ask immediately on interaction or on returning to the foreground. Collapse many tabs of the same account into one poll.
- How to check: insert a server-side update halfway between asks; the UI should show it on the next slot, not at once. Tighten the interval toward a continuous request and look at the empty-response share — if most answers are “no change”, waste has already outrun simplicity.