Short Pollinglesson 3 of 3 · 2 min read

When It's Honestly Fine

When it is the right answer

Polling gets sneered at in interviews, which is funny given how much of it runs in production at the companies doing the interviewing. The conditions for using it without apology are concrete.

Check your numbers first. Forty support agents polling a dashboard every 10 seconds is 4 requests a second. Building a WebSocket fleet, with its sticky routing and heartbeats and reconnect logic, to save 4 requests a second is theatre.

Check whether the window is bounded second. A payment confirmation page only needs to be fresh for the 30 seconds after checkout, so poll hard during that window and then stop, which costs nearly nothing.

Check what staleness your users tolerate third. A build dashboard showing green 15 seconds late has failed nobody.

The operational wins

Weigh the operational wins too, which have nothing to do with load. Polling is stateless, so it works untouched behind any CDN, any balancer, any serverless platform, and that last one supports polling out of the box and supports nothing else nearly as cleanly.

Enjoy what you do not have: no long-lived connections to drain during a deploy, no reconnect storms, no proxy quietly killing idle sockets after 60 seconds. You debug with curl and load test with any HTTP tool ever written.

Watch for the tells that you have outgrown it. Your interval keeps shrinking under product pressure. Your empty-response rate sits above 95 percent at real volume. Your users refresh by hand because the page feels dead.

Move when one of those shows up, to long polling if you must keep plain request semantics, or to server-sent events if your server can push. Until then, the boring loop with a timer is not a compromise. It is the right tool sized to the problem.

Worked example

Ana's team at a logistics company debates real-time infrastructure for an internal exceptions dashboard used by 35 dispatchers. One engineer sketches a WebSocket design with Redis pub/sub and sticky sessions, estimated at three weeks including deploy tooling. Ana counts instead: 35 users, a 10 second interval, 3.5 requests per second against an endpoint that reads one indexed Postgres view. They ship the polling version in a day and a half. Eight months later the dashboard has survived four framework upgrades and two AWS incidents without a single page about it, while the team that built WebSocket notifications for the customer app maintains a runbook for reconnect storms. The dispatchers never noticed the 10 seconds.

Short Polling: wrapping up

In the real world

01The AWS SDKs ship 'waiters' that are institutionalized short polling: aws ec2 wait and its cousins call Describe APIs every 15 seconds or so until the resource reaches the target state.
02Payment confirmation pages across the industry, including Stripe-based checkouts, poll the payment status endpoint every couple of seconds during the short window after submission rather than opening a push channel for a 30 second interaction.
03Jenkins' Poll SCM trigger checks the Git remote on a cron schedule, and plenty of teams that never wired up webhooks run their entire CI pipeline on it.
04Uptime monitors like Pingdom and UptimeRobot are short polling sold as a product: they request your endpoint every 30 to 60 seconds from multiple regions and alert on the answer.
05Third-party Twitter clients in the API v1.1 era refreshed home timelines by polling inside a 15-minute rate limit window, which is why they updated every 60 to 90 seconds instead of instantly.

Questions people ask

How do I choose a poll interval?

Start from the product's staleness tolerance, not from the server. If users are fine seeing changes 10 seconds late, poll every 10 seconds. Then check the math: clients divided by interval is your request rate, and if that number is uncomfortable, either lengthen the interval, cache the response, or switch to long polling or SSE. Adaptive intervals that speed up during active windows and slow down after repeated empty responses get you most of the benefit of both settings.

Is short polling ever cheaper than a push connection?

Often, yes. A poll is a stateless request that any CDN, load balancer, or serverless platform handles natively, while push requires held connections, heartbeats, reconnect logic, and servers that drain gracefully on deploys. At low client counts or with bounded freshness windows, the polling requests cost less than the engineering and operations of a connection fleet.

What is the actual difference between short and long polling?

Timing of the response. Short polling answers immediately, even with nothing, so freshness is capped by the interval and most responses are empty. Long polling parks the request until data arrives or a timeout fires, so responses almost always carry data and delivery latency drops to near real time while keeping ordinary HTTP semantics.

Quick review

Client sends an HTTP request at fixed intervals (every 5s, 10s, 30s) regardless of whether updates exist; Server responds immediately with new data or an empty response
Browser implementation:: setInterval(() => fetch('/updates'), 5000); Works with any standard HTTP server, no special infrastructure needed
Worst-case:: 99% of requests return empty if updates are infrequent
Load scales with client count, not data volume:: 10k clients polling every 5 s = 2,000 QPS of mostly-empty responses
Acceptable for:: admin dashboards with low update frequency, non-latency-sensitive status checks

the trade-off

High overhead relative to data received. Not truly real-time. Maximum freshness = poll interval.

in the room

Update frequency is predictable, delay of 5 to 30s is acceptable, and infrastructure simplicity matters most.

the short version

Small numbers, bounded windows, and staleness tolerance make polling the correct tool.