We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · API Design & Protocols
The client sends a request and the server holds it open until new data is available or a timeout is reached. A workaround for real-time updates before WebSockets existed.
In short
Long polling is a technique where a client sends an HTTP request and the server holds the connection open without responding until new data is ready or a timeout expires, then the client immediately sends another request. It lets a server push fresh data to a client over ordinary HTTP without the client constantly asking, and it was the standard way to fake real-time updates before WebSockets and Server-Sent Events were widely supported.
In short
Long polling is a technique where a client sends an HTTP request and the server holds the connection open without responding until new data is ready or a timeout expires, then the client immediately sends another request. It lets a server push fresh data to a client over ordinary HTTP without the client constantly asking, and it was the standard way to fake real-time updates before WebSockets and Server-Sent Events were widely supported.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Long Polling across a run of lessons, not one page. These 4 alone are about 52 minutes of step-by-step reading, every one with a quiz.
Hold the connection open until new data arrives, polling's smarter cousin.
One-way server push over HTTP, real-time updates without the complexity of WebSockets.
A request timeout limits how long a client waits for a full response. Learn how to pick the value, use timeout budgets, and retry without a storm.
Maximum time a client waits to establish a connection before giving up.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Long Pollingpay once,
yours for life
With normal HTTP, the client asks and the server answers right away. If the client wants to know about new data, it has to keep asking. Plain polling means asking every few seconds on a fixed timer, which wastes requests when nothing has changed and adds delay when something does change between polls.
Long polling flips the waiting. The client makes a request, and instead of answering immediately, the server holds the request open. It only sends a response when there is actually something new to deliver, or when a timeout (commonly 20 to 60 seconds) is reached. As soon as the client gets a response, it fires off a fresh request and the cycle repeats.
The result feels close to real time. When an event happens on the server, the response that was being held gets flushed back to the client within milliseconds, instead of waiting for the next fixed poll interval. From the browser's point of view it is still just regular HTTP request and response, so it works through old proxies, firewalls, and load balancers that do not understand newer protocols.
The client opens a request to an endpoint, for example GET /updates?since=12345. On the server, the handler does not return a response immediately. It registers a listener or blocks on a condition, waiting for an event that concerns this client, such as a new chat message or a changed order status.
Three things can end the wait. New data arrives and the server writes it into the held response and closes it. The timeout fires and the server returns an empty or no-change response so the connection does not stay open forever. Or the connection drops, in which case the client notices and reconnects.
Because each held request ties up a connection and often a server thread or async task for its whole lifetime, long polling demands a server that can keep many idle connections cheap. Synchronous, thread-per-request servers fall over fast here. Event-driven runtimes like Node.js, Go, or Java with NIO handle thousands of parked connections because a waiting request consumes almost no CPU. The client usually passes a cursor like a last-seen ID or timestamp so the server knows exactly what the client already has and can avoid sending duplicates or missing events during the brief gap between one response closing and the next request opening.
Long polling earns its place when you need server-to-client updates but cannot rely on WebSockets. That happens behind strict corporate proxies that block the WebSocket upgrade, on legacy browsers, or when your infrastructure (some CDNs, older load balancers) handles plain HTTP much more reliably than long-lived socket connections. It is also simpler to reason about because every exchange is a standard request and response that you can cache, log, and debug with normal HTTP tools.
The cost is overhead. Every cycle pays for a full HTTP request and response, including headers, and a new connection setup if keep-alive is not in play. Under high message rates the client spends most of its time reconnecting, which is wasteful compared to a single persistent WebSocket. Latency also has a floor: there is a small gap between one response closing and the next request opening, and any event landing in that gap waits for the next cycle.
For genuinely high-frequency, two-way, low-latency traffic such as multiplayer games, collaborative editors, or live trading, WebSockets are the better fit. For one-way streams of updates like notifications or a live feed, Server-Sent Events are simpler. Long polling is the pragmatic middle ground: more real-time than fixed-interval polling, more compatible than WebSockets, and good enough for moderate update rates.
Picture a chat app. A user has a conversation open and the browser sends GET /messages?roomId=42&after=998. The server has no new messages, so it parks the request and waits.
Twenty seconds later someone posts. The server's message handler wakes the parked request, writes the new message as JSON, and closes the response. The browser receives it in roughly the time it takes the message to travel the network, renders it, and instantly sends GET /messages?roomId=42&after=999 to wait for the next one.
If nobody posts for 30 seconds, the server returns an empty 204 or an empty array so the request does not hang indefinitely, and the browser reconnects. Facebook Chat ran exactly this pattern for years before WebSockets were standard, and many systems still keep long polling as the automatic fallback when a WebSocket connection cannot be established.
Facebook Chat
An early large-scale user of long polling for delivering chat messages before WebSockets were standardized, holding HTTP requests open until a message arrived.
Socket.IO
The real-time library uses HTTP long polling as its default transport and fallback, then upgrades to WebSockets when the connection allows it.
BOSH (XMPP over HTTP)
The Bidirectional-streams Over Synchronous HTTP standard is essentially long polling, used by web-based chat clients to run XMPP through ordinary HTTP.
Slack
Falls back to long polling when corporate proxies or firewalls block the WebSocket connection it normally uses for real-time messaging.
Regular polling sends a request on a fixed timer, say every 5 seconds, and the server answers immediately whether or not anything changed. Long polling sends a request and the server holds it open, answering only when new data is ready or a timeout hits. Long polling delivers updates faster and wastes far fewer requests when little is happening.
Usually no for high-frequency or two-way traffic. WebSockets keep one persistent connection open for both directions with very low overhead, while long polling pays for a full HTTP request and response on every cycle. Long polling wins only on compatibility, working through old proxies, firewalls, and browsers that block WebSocket upgrades.
Typically 20 to 60 seconds. The server closes the request earlier the moment new data arrives. The timeout exists so connections do not hang forever and so intermediaries do not silently kill an idle connection; when it fires, the client just reconnects.
No. It opens and closes a connection per cycle. Each response ends the current request, and the client immediately starts a new one. That is the key difference from WebSockets and Server-Sent Events, which hold a single connection open continuously.
There is a brief gap between one response closing and the next request opening, and an event in that gap could be missed. The standard fix is to send a cursor such as a last-seen ID or timestamp with each request, so the server can return everything that happened since then and nothing is lost.
WebSocket
A protocol for full-duplex communication over a single TCP connection. Unlike HTTP, the server can push data to the client without being asked.
SSE
Server-Sent Events: a one-way channel where the server pushes updates to the client over HTTP. Simpler than WebSockets when you only need server-to-client streaming.
HTTP
The protocol powering the web. A request-response model where clients ask for resources and servers respond. Stateless by design.
Rate Limiting
Controlling how many requests a client can make in a given time window. Protects your API from abuse and ensures fair usage.
GraphQL
A query language for APIs where the client specifies exactly what data it needs. No over-fetching, no under-fetching. One endpoint to rule them all.
gRPC
A high-performance RPC framework by Google using Protocol Buffers and HTTP/2. Much faster than REST for service-to-service communication.
This page explains the idea. The "Long Polling" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Long Polling lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Long Polling in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
