We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Messaging Event Systems
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Messaging Event Systems
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Every kid has done this on a road trip. "Are we there yet?" No. Ten seconds later: "Are we there yet?" Still no. Ten seconds later: "Are we there yet?"
That's polling. You keep asking the same question, over and over, at a fixed interval, until the answer changes.
It sounds ridiculous, and in many cases it is. But polling is the oldest, simplest, and most widely-used method for checking whether new data is available. Before WebSockets existed, before Server-Sent Events, before any of the fancy real-time tech we have today, there was polling. And honestly, it still powers a shocking amount of the internet.
Your email client checking for new mail every 30 seconds? Polling. That stock ticker refreshing prices? Probably polling. The "checking for updates" spinner in your operating system? Polling.
The reason it survives is brutally simple: it works everywhere, with any server, using nothing but plain requests. No special protocols, no persistent connections, no server-side support needed. You just keep asking.
The mechanism is dead simple:
That's it. There's no magic here.
The polling interval is the key decision. Too short (every 100ms) and you're hammering your server with requests, most of which return nothing. Too long (every 60 seconds) and your users see stale data for up to a full minute.
There's no "right" interval. It depends entirely on how fresh the data needs to be and how much load your server can handle. Slack's original desktop app polled every few seconds for new messages. A weather dashboard might poll every 15 minutes. A build status page might poll every 30 seconds.
The math tells the story. At a 5-second interval with 10,000 connected users, your server processes 2,000 requests per second. During a quiet hour when zero messages arrive, that's 7.2 million completely wasted requests. Each one opens a connection, parses HTTP headers, runs a database query, serializes a response, and sends it back. All to say "nothing changed."