Long Polling

HTTP is a request-response protocol. You ask, the server answers, the connection closes. This works well for most web interactions, but it breaks down for real-time updates.

Think about a chat application. Your friend sends you a message. How does your browser know? With plain HTTP, it doesn't, at least not until you ask. The naive solution is to ask over and over again, every few seconds: "Anything new?" That's short polling, and it's as inefficient as it sounds.

Long polling was the industry's clever workaround before WebSockets became mainstream. It's worth understanding not just for historical context, but because it still appears in production systems today.

The Problem: HTTP Was Never Built for Push

Standard HTTP works like this:

1. Client sends a request
2. Server processes it and immediately sends a response
3. Connection closes

There's no built-in mechanism for the server to say "hold on, I'll reply when I have something." The server can't initiate contact. It can only respond.

For anything real-time, chat messages, notifications, live scores, this is a serious limitation.

How Long Polling Works

Long polling flips the timing. Instead of the server answering immediately with "nothing new," it holds the request open until there's actually something to return.

Here's the flow:

1. Client sends a request: "Any new messages?"
2. Server holds the connection open and doesn't respond yet
3. When a new message arrives (or a timeout is hit), the server responds
4. Client immediately opens a new request

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Long polling keeps the HTTP connection open instead of responding immediately with "nothing new." The server holds the request until an event arrives or the timeout expires (typically 30-60 seconds). The client is blocked — it made a real HTTP request and is waiting for the response. No new TCP connection is needed while waiting, and no CPU is burned on either side. This is fundamentally different from short polling, where the client would close the connection and make a fresh request every few seconds regardless of whether anything changed.

1 / 10.5×1×2×3×Playground

Long polling — client sends request, server holds connection until event fires

From the user's perspective, this feels nearly real-time. The moment an event happens on the server, the waiting client gets notified.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

When an event arrives (a new chat message, a notification, a status change), the server wakes up the held request and sends the response immediately. The client parses the data and fires off the next poll without delay — creating a near-continuous loop. From the user's perspective, updates feel instant. From the infrastructure perspective, each server is holding many open connections but doing no work until an event fires. This requires async I/O on the server (Node.js, async Python, Go) to be efficient — a thread-per-connection model would exhaust threads at scale.

1 / 10.5×1×2×3×Playground

Event fires — server responds immediately, client reconnects

The timeout part matters. If nothing happens for 30 seconds, the server sends an empty response. The client then immediately reconnects. This prevents connections from hanging forever.

Short Polling vs Long Polling vs WebSockets

Short polling wastes requests. Every poll is a round-trip, most of which return "nothing new." At scale, say 100,000 clients polling every 3 seconds, that's 33,000 requests per second hitting your servers, most of them useless.

Long polling cuts those wasted requests dramatically. The connection stays open, and you only get a response when there's something worth responding to.

WebSockets are generally better than both for true real-time applications, but they come with operational complexity, especially around load balancing. See the WebSockets article for details.

Real Examples

Gmail (circa 2008-2012)

Before Gmail moved to WebSockets, it used long polling to deliver new email notifications in near real-time. Your browser held a connection open to Google's servers. When a new email arrived, the server pushed a response down that open connection, triggering the "(1)" in your browser tab.

Early Facebook Chat

Facebook Chat (launched 2008) ran on long polling for years. At Facebook's scale, even long polling was a massive engineering challenge. They built a custom Erlang-based server called ejabberd to handle millions of simultaneous held connections.

Basecamp and Older Collaboration Tools

Many SaaS apps from the late 2000s and early 2010s used long polling for live updates, comment notifications, and real-time collaboration features, before WebSockets had broad browser and infrastructure support.

Pros and Cons

Pros:

• Works over standard HTTP with no special infrastructure needed
• Compatible with existing load balancers, proxies, and firewalls
• Simpler to implement than WebSockets
• Stateless between responses (servers don't maintain persistent state per connection)

Cons:

• Still involves repeated connection overhead (TCP handshake and HTTP headers on reconnect)
• Server must hold many open connections simultaneously, requiring async I/O to be efficient
• Header overhead on every reconnect adds up
• Not truly bidirectional, since the client still initiates every exchange

When to Still Use Long Polling

WebSockets are the right choice for most new real-time systems. Long polling still makes sense when:

• You need to support environments where WebSockets are blocked (some corporate proxies, older clients)
• You're building a simple notification mechanism where sub-second latency isn't required
• Your infrastructure doesn't easily support sticky sessions, which WebSockets often require

Summary

Long polling is an HTTP trick that achieves near-real-time updates by holding a request open until data is available. It powered real-time features at Gmail, early Facebook Chat, and countless other apps before WebSockets became mainstream. Today it's a useful fallback, but for most new real-time systems, WebSockets or Server-Sent Events are the better choice.