What Polling Does
Polling is how a screen updates itself without the user refreshing — the browser asks the server periodically whether anything has changed.
Where to find it
Architect Panel → Background Messaging:
- Polling — the configured polls, their scope and frequency
Architect Panel → Dashboards:
- Explore — dashboards, a common consumer of live updates
What a poll is configured with
- A name.
- A scope — what it covers.
- A default period — how often it asks.
- A life — how long it keeps asking.
- A callback function — what runs to produce the answer.
Where it earns its place
- Shared queues. A work list several people pick from should show what is actually left.
- Notifications and message counts.
- Dashboards left open on a screen.
- Anything two people act on at once, where stale information causes duplicated work.
The cost is multiplied by everybody
The thing to hold in mind. A poll every ten seconds is six requests a minute per user — trivial for one person and, with two hundred people signed in, twelve hundred requests a minute arriving whether or not anything changed.
Polling is a load you choose to add, and it is proportional to your user count rather than to activity.
Most screens do not need it
A form somebody is filling in does not need to update. A report they ran two minutes ago does not either. The honest test: would a person act differently if this were thirty seconds fresher?
If not, it does not need polling, and adding it is load for nothing.
Poll for the notification, not the data
Where you can, poll for something small — a count, a flag saying something changed — and fetch the detail only when it has. That keeps the frequent request cheap and the expensive one rare.
Polling that re-fetches a full dataset every interval is the pattern that causes trouble at scale.
Consider push instead
For genuinely event-driven updates, push notifications avoid the whole arrangement — the server tells the browser when something happens rather than being asked constantly. Polling suits steady updating; push suits discrete events.
The callback is code that runs constantly
Whatever the poll calls runs on every poll for every user. Something inefficient there is multiplied more than anywhere else in the application — keep it tight and make sure what it touches is indexed.
Worked example
A service desk polls the shared queue every thirty seconds, returning only a count and a change marker; the list is re-fetched only when the marker moves. Individual ticket screens do not poll at all, because nothing about them changes while somebody is typing.
Recommendations
- Ask whether anybody would act differently before adding a poll.
- Poll for a marker, fetch detail on change.
- Keep callbacks tight — they run constantly.
- Prefer push for discrete events.