Long Polling

Long polling is a technique where the client makes an HTTP request and the server holds the connection open until new data is available or a timeout occurs, simulating server-push over standard HTTP.

What It Really Means

Regular polling is wasteful — the client asks "Any updates?" every second, and the server almost always says "No." This wastes bandwidth and server resources, and updates are delayed by up to one polling interval.

Long polling flips this around. The client sends a request, and the server holds it open. When new data arrives (or a timeout occurs), the server responds. The client immediately sends another request. This creates a near-real-time update channel using standard HTTP — no WebSocket support required.

Long polling was the primary real-time technique before WebSockets and SSE. It is still used as a fallback in environments where WebSocket upgrades are blocked (corporate proxies, older infrastructure) and in protocols like CometD and Bayeux.

How It Works in Practice

Regular Polling vs Long Polling

Sequence Diagram

Implementation

Server (Python with Flask):

Client (JavaScript):

Trade-offs

Use long polling when:

• WebSocket and SSE are not available (corporate proxies, legacy systems)
• You need a universal fallback mechanism
• Updates are infrequent (long-polling efficiency improves with less frequent updates)

Avoid long polling when:

• High-frequency updates (better with SSE or WebSocket)
• You need bidirectional communication (use WebSocket)
• Server resources are limited (each held connection consumes a thread/connection)

Common Misconceptions

• "Long polling is obsolete" — It is the most compatible real-time technique. Libraries like Socket.IO use it as a fallback when WebSocket negotiation fails.
• "Long polling is the same as regular polling" — Regular polling sends requests at fixed intervals regardless of data availability. Long polling holds the connection until data arrives, reducing unnecessary requests.
• "Long polling does not work with load balancers" — It works with any HTTP load balancer. Unlike WebSocket, it does not require special protocol support.
• "Long polling wastes server connections" — True, each waiting client holds a connection. But async frameworks (Node.js, asyncio) handle thousands of concurrent long-poll connections efficiently without thread-per-connection overhead.

How This Appears in Interviews

1. "Compare real-time update strategies" — Explain polling, long polling, SSE, and WebSocket. Discuss when each is appropriate.
2. "Design a notification system that works everywhere" — Long polling as universal fallback, SSE for modern browsers, WebSocket for mobile apps.
3. "How does Slack/Discord handle real-time messaging?" — WebSocket as primary, long polling as fallback. Discuss connection management and message ordering.

Related Concepts

• WebSocket Protocol — bidirectional alternative for real-time communication
• Server-Sent Events — simpler one-way streaming alternative
• HTTP/2 Multiplexing — reduces long polling overhead
• Connection Pooling — managing connections for polling clients
• System Design Interview Guide
• Algoroq Pricing — access all concept deep-dives