Short Polling: Asking Again on a Timer

Plain HTTP requests every few seconds, and most of them come back empty.

Short polling means the client sends an ordinary HTTP request on a fixed timer, every few seconds, and asks whether anything has changed. The server answers at once, with news or with nothing. It needs no special support on either side, which is why it is often the first version of any live feature.

Who starts, and which way. The client starts every exchange. Data flows from server to client, but only inside an answer to a question the client asked.

Three polls five seconds apart, two of them empty

Freshness is the interval. News waits until the next poll, so with a five-second timer it arrives up to five seconds late. Shortening the timer makes it fresher and sends more requests.

What it costs the server. One full request for every client, every interval, whether or not anything changed. Ten thousand clients polling every five seconds send 2,000 requests a second, and if the data changes once a minute, almost all of them come back with nothing new. Each one still passes through the load balancer, is authenticated, and reads from a cache or the database.

Short polling

Use it when

A delay of the polling interval is acceptable, such as a job status or a parcel tracker
The number of clients is small, or the interval long
You want the live feature working before building anything more

Avoid it when

Updates must arrive within a second
Many clients poll data that rarely changes, so most requests are wasted

One product that uses it. The Telegram Bot API's getUpdates method returns at once by default, which its documentation calls usual short polling: a bot calls it again and again to collect new messages.

So reach for short polling when a few seconds late is fine and the client count is modest, and count the empty requests before it grows.

← → move through sections and cards