Long Polling vs Server-Sent Events: Which for Real-Time Updates?
Compare long polling and Server-Sent Events for real-time updates — mechanics, overhead, reconnects, and when to use each.
Expected Interview Answer
Long polling simulates real-time delivery by having the client repeatedly open an HTTP request that the server holds open until new data exists or a timeout hits, while Server-Sent Events (SSE) open one persistent HTTP connection over which the server streams a continuous sequence of events, making SSE simpler and more efficient for one-directional server-to-client updates.
With long polling, the client sends a request, the server delays its response until an update is available (or a timeout passes), and the client immediately reopens a new request after each response, which means a fresh HTTP request/response cycle (headers, TCP overhead) for every update cycle. SSE instead keeps a single HTTP connection open with the Content-Type text/event-stream, and the server writes a stream of discrete events down that one connection indefinitely, with the browser’s native EventSource API handling automatic reconnection and a Last-Event-ID header for resuming after a drop. SSE is strictly one-directional (server to client only), works over plain HTTP so it passes through existing proxies and load balancers more easily than WebSockets, and is a natural fit for notification feeds, live scores, or streaming AI responses. Long polling remains useful when infrastructure cannot support long-lived streaming connections at all, or when updates are rare enough that per-request overhead does not matter, but at meaningful scale SSE is generally cheaper per update and simpler to reason about than repeatedly re-establishing HTTP requests.
- SSE keeps one connection open instead of re-establishing an HTTP request per update
- SSE has built-in auto-reconnect and resume support via the browser EventSource API
- SSE runs over plain HTTP, so it traverses existing proxies/load balancers more easily than WebSockets
- Long polling still works where infrastructure cannot hold long-lived streaming connections at all
AI Mentor Explanation
Long polling is like a fan calling the stadium hotline over and over, each time waiting on hold until the operator has fresh score news or the call times out, then hanging up and immediately redialing. Server-Sent Events is like that same fan staying on one open line to a dedicated commentary feed that reads out every scoring update as it happens, without ever hanging up. The open-line approach avoids the cost of constantly redialing, and if it briefly drops, the commentator resumes from the last update announced. That single persistent stream versus repeated redialing is exactly the SSE-versus-long-polling trade-off.
Step-by-Step Explanation
Step 1
Client opens a request
Long polling: client sends a request the server holds open; SSE: client opens one text/event-stream connection.
Step 2
Server delivers when data is ready
Long polling responds and closes per update; SSE writes a discrete event onto the still-open stream.
Step 3
Client reacts to the update
Long polling parses the response body; SSE’s EventSource fires an onmessage handler per event.
Step 4
Reconnect after a drop
Long polling simply reissues a request; SSE’s EventSource auto-reconnects and sends Last-Event-ID to resume.
What Interviewer Expects
- Explains the mechanics of both: repeated held requests vs one persistent event stream
- Notes SSE is one-directional and long polling can carry any HTTP semantics
- Mentions SSE’s built-in reconnect/resume via EventSource and Last-Event-ID
- Discusses when long polling is still the pragmatic choice (constrained infra, rare updates)
Common Mistakes
- Confusing SSE with WebSockets (SSE is one-directional, over plain HTTP)
- Not mentioning the per-cycle HTTP overhead of long polling at scale
- Forgetting that SSE has native browser reconnect support
- Assuming long polling is obsolete rather than acknowledging valid use cases
Best Answer (HR Friendly)
“Long polling means the client keeps asking the server “anything new?” and each request waits until there is an answer, then asks again. Server-Sent Events instead keeps one connection open and the server just streams updates down it as they happen, which is more efficient and comes with automatic reconnect built into the browser. We use SSE when updates flow one-way from server to client and want something simpler and cheaper than constant re-asking.”
Code Example
// Server (Express)
app.get("/events", (req, res) => {
res.set({
"Content-Type": "text/event-stream",
"Cache-Control": "no-cache",
Connection: "keep-alive",
})
res.flushHeaders()
const send = (id, data) => {
res.write(`id: ${id}\n`)
res.write(`data: ${JSON.stringify(data)}\n\n`)
}
const unsubscribe = subscribeToUpdates((event) => send(event.id, event.payload))
req.on("close", unsubscribe)
})
// Client
const source = new EventSource("/events")
source.onmessage = (e) => {
const update = JSON.parse(e.data)
renderUpdate(update)
}
// Reconnects automatically; sends Last-Event-ID to resume from the last idFollow-up Questions
- Why is SSE strictly one-directional, and what do you use when the client also needs to send data?
- How does the Last-Event-ID header let an SSE client resume after a disconnect?
- When would long polling still be the right infrastructure choice over SSE?
- How does SSE compare to WebSockets for a live notifications feature?
MCQ Practice
1. What is the main inefficiency of long polling compared to SSE?
Each long-polling cycle opens and closes a fresh HTTP request, incurring repeated header and connection overhead compared to SSE’s single open stream.
2. Which direction does Server-Sent Events support?
SSE is strictly one-directional: the server streams events to the client over one open HTTP connection.
3. What browser feature gives SSE automatic reconnection with resume support?
EventSource automatically reconnects on drop and sends Last-Event-ID so the server can resume the stream from the last delivered event.
Flash Cards
What is long polling? — Client repeatedly opens a request the server holds until data is ready or it times out, then reopens immediately.
What is SSE? — A single persistent HTTP connection over which the server streams a sequence of one-directional events.
How does SSE handle reconnects? — The browser EventSource API auto-reconnects and sends Last-Event-ID to resume.
When is long polling still appropriate? — When infrastructure cannot support long-lived streaming connections or updates are too rare to matter.