Long Polling vs WebSockets
Both enable near-real-time communication between client and server. Long polling keeps an HTTP connection open until new data is available.
Quick answer: Long Polling vs WebSockets
Long Polling vs WebSockets is covered here as a practical architecture tradeoff. Both enable near-real-time communication between client and server. Long polling keeps an HTTP connection open until new data is available. Use it when comparing two architecture choices and explaining the operational cost, latency, reliability, and team-complexity impact of each option.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
Long Polling vs WebSockets
Both enable near-real-time communication between client and server. Long polling keeps an HTTP connection open until new data is available. WebSockets provide a persistent bidirectional connection.
The Case for Long Polling
Client sends an HTTP request. Server holds it open until new data or timeout. Client immediately re-requests.
What you gain: Works everywhere (standard HTTP). Simpler to implement. Works through all firewalls/proxies. Easy to load balance.
What you lose: Higher latency (new request after each response). More overhead (HTTP headers per request). Server holds connections idle. Not truly real-time.
Best when: Updates are infrequent; Infrastructure does not support WebSockets; Simple implementation is preferred; One-directional updates (server to client).
The Case for WebSockets
Persistent TCP connection after HTTP upgrade handshake. Full-duplex bidirectional communication.
What you gain: True real-time (sub-100ms latency). Low overhead (2-byte frame headers). Bidirectional communication. Efficient for high-frequency updates.
What you lose: Stateful connections (harder to scale). Not all proxies support WebSocket upgrade. Requires reconnection logic. More complex server infrastructure.
Best when: Real-time is critical (chat, gaming, trading); High-frequency updates (live dashboards, feeds); Bidirectional communication needed; Low latency is essential.
Side-by-Side
| Long Polling | WebSockets | |
|---|---|---|
| Strengths | Works everywhere (standard HTTP) | True real-time (sub-100ms latency) |
| Weakness | Higher latency (new request after each response) | Stateful connections (harder to scale) |
| Use when | Updates are infrequent | Real-time is critical (chat, gaming, trading) |
In the Real World
Slack uses WebSockets for real-time messaging — every keystroke in typing indicators is a WebSocket message.
Facebook historically used long polling for chat before migrating to WebSockets for better performance.
Stock trading platforms use WebSockets for real-time price feeds where every millisecond matters.
The Interview Take
Default to WebSockets for real-time features in your system design. Mention long polling as a fallback for clients that cannot support WebSockets.
Source | System-Design-Overview
Real-World Decision Framework
Long polling and WebSockets both enable real-time communication, but they work fundamentally differently. Long polling uses standard HTTP — the client sends a request, and the server holds it open until new data is available. WebSockets upgrade an HTTP connection to a persistent, bidirectional channel.
When Long Polling Wins
Long polling is simpler and works everywhere HTTP works:
- Notification systems: Check for new notifications by holding a request open. When a notification arrives, respond and the client immediately sends a new request.
- Simple chat: Early versions of Facebook Messenger used long polling because it worked through corporate firewalls and proxies that blocked WebSockets.
- Legacy environments: Systems behind strict firewalls or proxies that only allow HTTP traffic.
- Low-frequency updates: If updates come every 10-30 seconds, long polling is efficient enough.
Advantages: Works through all proxies and firewalls, uses standard HTTP, trivial to implement, stateless on the server side.
When WebSockets Win
WebSockets provide true real-time bidirectional communication:
- Live chat: Slack, Discord, and WhatsApp use WebSockets for instant message delivery with typing indicators.
- Collaborative editing: Google Docs and Figma push character-by-character changes over WebSockets.
- Live gaming: Online multiplayer games need sub-50ms bidirectional communication.
- Financial dashboards: Stock trading platforms push price updates multiple times per second.
- IoT: Connected devices stream sensor data continuously.
Advantages: Lower latency, lower overhead (no repeated HTTP headers), bidirectional communication, server can push without client requesting.
Performance Comparison
| Factor | Long Polling | WebSocket |
|---|---|---|
| Connection overhead | High (new HTTP request each time) | Low (single persistent connection) |
| Latency | 100-500ms (depends on poll interval) | 1-10ms |
| Server memory | Low (stateless) | Higher (maintains connection state) |
| Scalability | Easier (standard HTTP infra) | Harder (sticky sessions, connection limits) |
| Firewall compatibility | Excellent | Good (some block port 443 upgrade) |
The Decision in Interviews
For most real-time features, mention WebSockets as the preferred approach, but acknowledge that you would fall back to long polling for compatibility. Mention that ASP.NET Core SignalR does exactly this — it negotiates WebSocket first, then falls back to Server-Sent Events, then long polling.
.NET Implementation
Long polling: Simple HTTP endpoint that uses TaskCompletionSource<T> to hold the response until data arrives. WebSocket: Use ASP.NET Core SignalR — it abstracts the transport, provides automatic reconnection, and scales with Azure SignalR Service for thousands of connections. For raw WebSockets, use WebSocketManager middleware.
Original DosiBridge notes for Long Polling vs WebSockets
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Long Polling vs WebSockets is to connect the concept to an integration boundary where bad contracts become customer-facing outages. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Decision Boundary: For Long Polling vs WebSockets, decide the decision boundary before choosing tools; otherwise the design looks clean but fails when long changes.
- Reversal Cost: For Long Polling vs WebSockets, decide the reversal cost before choosing tools; otherwise the design looks clean but fails when polling changes.
- Operating Cost: For Long Polling vs WebSockets, decide the operating cost before choosing tools; otherwise the design looks clean but fails when vs changes.
- Team Maturity: For Long Polling vs WebSockets, decide the team maturity before choosing tools; otherwise the design looks clean but fails when websockets changes.
- Growth Trigger: For Long Polling vs WebSockets, decide the growth trigger before choosing tools; otherwise the design looks clean but fails when long changes.
Production review question
If a team adopts Long Polling vs WebSockets, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track long-websockets health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Long Polling vs WebSockets, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.