Long Polling is a technique where the client sends an HTTP request and the server keeps the request open until new data is available or a timeout occurs.
It is commonly used when real-time updates are needed but a persistent WebSocket connection is not being used.
1. Normal Polling vs Long Polling
In normal polling, the client repeatedly sends requests at fixed intervals.
sequenceDiagram
Client->>Server: Any new data?
Server-->>Client: No
Client->>Server: Any new data?
Server-->>Client: No
Client->>Server: Any new data?
Server-->>Client: New dataThis can generate many unnecessary requests.
2. How Long Polling Works
With long polling, the server does not immediately return an empty response. It keeps the request open while waiting for new data.
sequenceDiagram
Client->>Server: Request for updates
Note over Server: Wait for new data
Server-->>Client: New data
Client->>Server: New request
Note over Server: Wait again
Server-->>Client: New data3. Long Polling Example
Imagine a notification system.
Client: Any new notification?
Server:
Wait...
Notification arrives
Server: Here is the notification.After receiving the response, the client sends another long-polling request.
4. Long Polling Flow
flowchart LR
Client --> Request["HTTP Request"]
Request --> Server["Server"]
Server --> Wait["Wait for Event"]
Wait --> Response["Response"]
Response --> Client
Client --> Request5. Why Use Long Polling?
Long polling can provide near-real-time communication while continuing to use HTTP request-response communication.
It can be useful when:
- WebSocket is unavailable.
- The application needs near-real-time updates.
- The infrastructure is primarily HTTP based.
- Updates are relatively infrequent.
6. Long Polling vs Normal Polling
| Normal Polling | Long Polling |
|---|---|
| Request at fixed intervals | Request stays open while waiting |
| Many empty responses | Fewer unnecessary responses |
| Simple | More efficient for event-driven updates |
| Higher request frequency | Lower request frequency |
7. Long Polling vs WebSocket
| Long Polling | WebSocket |
|---|---|
| HTTP requests | Persistent WebSocket connection |
| Connection ends after response | Connection remains open |
| Client reconnects after each response | No new request for every message |
| Higher overhead | Lower messaging overhead after connection |
| Useful fallback technique | Designed for persistent real-time communication |
8. Long Polling vs SignalR
SignalR can use long polling as one of its supported transports when a suitable persistent transport such as WebSocket is not being used.
flowchart TD
SignalR["SignalR"]
SignalR --> WebSocket["WebSocket"]
SignalR --> SSE["Server-Sent Events"]
SignalR --> LongPolling["Long Polling"]9. Long Polling in a Scaled System
Long-polling requests can remain open for a significant amount of time. When multiple application servers are involved, load balancing and connection handling need to be considered.
flowchart LR
Client --> LB["Load Balancer"]
LB --> Server1["API Server 1"]
LB --> Server2["API Server 2"]Depending on the application design, shared state or messaging infrastructure may be required so that an event can reach the client regardless of which server is holding the request.
10. Advantages
- Works using standard HTTP.
- Simple client-server model.
- Can provide near-real-time updates.
- Useful when WebSocket is unavailable.
11. Disadvantages
- HTTP request overhead remains.
- Connections may remain open for long periods.
- Repeated requests are required after responses.
- Large numbers of clients can increase server connection usage.
- Generally less efficient than a persistent WebSocket connection for frequent real-time messaging.
12. Important Interview Questions
- What is long polling?
- How is long polling different from normal polling?
- How does long polling work?
- Long polling vs WebSocket?
- Long polling vs SignalR?
- Why would you use long polling?
- What are the disadvantages of long polling?
- How does long polling behave behind a load balancer?
Key Takeaways
- Long polling keeps an HTTP request open while waiting for new data.
- The server responds when data becomes available or the request times out.
- The client sends another request after receiving the response.
- It can provide near-real-time communication without requiring WebSocket.
- SignalR can use long polling as a transport.
- WebSocket is generally more suitable for continuous bidirectional real-time communication.
Conclusion
Long polling is a bridge between traditional HTTP polling and persistent real-time communication. It reduces unnecessary polling requests while continuing to use the HTTP request-response model.
Polling → Repeated requests
Long Polling → Request waits for data
WebSocket → Persistent bidirectional connection
SignalR → Higher-level real-time framework