We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Messaging Event Systems
Free preview: the first 2 parts of this 6-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”
You just learned that regular polling wastes a massive amount of resources. The client asks "anything new?" every few seconds, and the server almost always responds "nope." Rinse and repeat, thousands of times, with nothing to show for it.
So someone had a clever idea: what if the server didn't respond immediately when there's nothing new? What if it just held the connection open and waited until something actually happened?
That's long polling. And it was the backbone of real-time web applications for over a decade. Facebook's original chat system? Long polling. Gmail's inbox notifications before they switched to other methods? Long polling. Slack's early versions? Long polling.
It's the trick that made the web feel "live" before WebSockets existed.
Long polling flips the script on regular polling:
The server is saying: "I'll get back to you when I actually have something to tell you."
This eliminates nearly all the wasted requests. Instead of 12 empty responses per minute (polling every 5 seconds), you get maybe 1-2 responses, only when something actually happens.
The implementation detail most tutorials skip: how does the server know when new data arrives while holding a request? Three common approaches: