Design Refresh Timing for a Crowd

Systems & Architecture · real-time, performance, scale

Updated 2026-08-04

Remember that your interface is running in thousands of browsers at once. A polite thirty second refresh becomes a thundering herd when every copy fires on the same clock tick.
Scatter every automatic interval by a random amount. Refreshing at thirty seconds plus up to five random seconds spreads the same load across a window instead of stacking it on one instant.
Never schedule work on a round number. Refreshing on the minute puts your traffic on the same boundary as every scheduled job in the world, including your own.
Watch for the moments that synchronize users without any timer at all:

Stagger reconnection after a disconnect. If every client retries immediately when the service returns, the service goes down again and the user reads it as a product that cannot stay up.
Back off when the tab is not visible, and stop entirely when the device is asleep. A background tab polling every five seconds is a battery complaint and a load problem at the same time.
Collapse repeated manual refreshes into one request. A user pressing refresh four times should produce one fetch and one visible response.
Slow the interval down when nothing is changing. A screen that has not changed in ten minutes does not need the same cadence as one that changes every second.

One client's refresh interval is a detail, and the same interval across every client at once is an outage.