Side by side
| Dimension | Long polling | WebSockets |
|---|---|---|
| Communication model | Held HTTP request; client sends another after each response | Persistent, full-duplex message connection |
| Update latency | Immediate while a request is waiting; gaps between requests | Immediate while connected, without request renewal |
| Per-update overhead | HTTP request and response overhead; batching helps | Small message frames after connection setup |
| Client-to-server traffic | Separate HTTP requests | Messages on the same connection |
| Idle resources | Pending requests and connections; periodic timeout renewals | Open connections; optional heartbeat traffic |
| Infrastructure | Ordinary HTTP routing; request timeouts need tuning | WebSocket-aware proxies, idle timeouts, and connection draining |
| Scaling | Concurrent pending requests plus renewal request rate | Concurrent connections plus message throughput |
| Recovery | Next request can carry a replay cursor | Reconnect and resubscribe with a replay cursor |
The differences that matter
Long polling is not periodic short polling. The server holds a request until data arrives or a timeout expires, then the client immediately issues another request. An event can arrive with low latency while a request is pending. The design must cover events arriving between requests, usually through retained events and a client cursor.
Traffic frequency changes the cost comparison. Long polling repeats HTTP request processing after responses and timeouts, although one response can batch several events. WebSockets amortize setup across many messages and carry traffic in both directions. Neither approach eliminates the cost of keeping large numbers of clients connected, and neither requires one operating-system thread per connection.
Both need a route from an event producer to the server currently serving a client. With WebSockets, that connection stays attached to one server until it closes. Long-poll requests can land on different servers, but only if subscriptions, cursors, and pending-event access are designed for that. A broker or shared event stream can connect either transport to the rest of the system.
The transport does not provide durable application delivery. Both need explicit replay, deduplication, authorization, and slow-client policies. WebSockets preserve message order on a live connection, but reconnects and multiple producers still require application sequencing. For either option, bound buffers and decide whether lagging clients receive every event, a snapshot, or only the latest value.
Choose Long polling when
- Updates are infrequent, mostly server-to-client, and the existing HTTP stack supports held requests without expensive resource use.
- You need a fallback for clients or network paths where WebSocket connections cannot be established reliably.
- Client writes already use HTTP APIs, and a cursor-based HTTP endpoint is sufficient for receiving updates.
- You want to reuse existing HTTP authentication and routing, and have verified that proxy timeouts and pending-request capacity support the workload.
Choose WebSockets when
- Clients exchange frequent messages in both directions, such as chat messages, typing indicators, or collaborative edits.
- A sustained stream makes repeated HTTP request processing and headers material to capacity or bandwidth.
- Avoiding gaps between long-poll requests matters for a continuous interactive experience.
- You can operate connection-aware gateways with heartbeats, bounded send queues, reconnect handling, and graceful connection draining.
A worked example
A support dashboard that becomes live chat
Assume 100,000 connected agents and a 30-second long-poll timeout. With almost no events, timeout renewals alone produce roughly 3,300 requests per second, while about 100,000 requests remain pending. That can be reasonable if the HTTP stack supports it and updates are rare. Now suppose each agent receives two events per second. Without batching, long polling approaches 200,000 response-and-renewal cycles per second, plus separate requests for outgoing messages. WebSockets retain roughly the same connection count but avoid renewing an HTTP request for each delivered event. For this sustained interactive workload, choose WebSockets, then size gateways for message throughput and per-connection memory. Keep durable messages and replay cursors outside the gateways so reconnects do not lose chat history.
In the interview
- Start with concurrent clients, updates per client, payload size, traffic direction, and a freshness target. Do not justify WebSockets merely by saying the system is real time.
- Estimate both open connections and request or message rates. For mostly idle long polling, timeout renewals alone are approximately connected clients divided by the hold timeout in seconds.
- Draw the delivery path from durable write to broker to connection server to client. Expect questions about subscription routing, hot-topic fan-out, and what happens when a connection server fails.
- Explain reconnects before claiming reliable delivery: cursor or sequence number, retention window, duplicate handling, and snapshot fallback. Then cover reconnect jitter, slow clients, and authorization checks on subscriptions.
Common mistakes
- Confusing long polling with short polling and claiming every event must wait for the next polling interval.
- Calling long polling stateless or connection-free. Each outstanding request occupies resources even if application state is stored elsewhere.
- Claiming WebSockets guarantee durable delivery or exactly-once processing. A socket failure can leave the sender unsure whether the application received a message.
- Assuming WebSockets automatically solve scaling. Connection capacity, broker fan-out, slow consumers, proxy limits, and rolling deployments still need explicit designs.
Where it comes up
Interview questions where choosing between Long polling and WebSockets comes up.
- Design a chat app like WhatsAppThe choice affects bidirectional messaging, typing indicators, connection routing, and recovery after disconnects.
- Design Google DocsFrequent edits and cursor updates make transport overhead, latency, and reconnect replay central design decisions.
- Design an ETA and live location sharing serviceLocation publishing and viewer subscriptions require an explicit choice of transport, freshness policy, and reconnect behavior.
- Design a real-time stock price feedSustained quote delivery exposes per-update overhead, slow-client handling, and latest-value recovery requirements.
- Design Facebook live commentsLarge viewer populations make connection capacity, request renewal rates, and bounded fan-out important to the transport choice.
- Design Dropbox or Google DriveA cursor-based change feed can use long polling or WebSockets while keeping file transfers on separate HTTP paths.
Questions people ask
Are WebSockets faster than long polling?
WebSockets avoid request renewal and usually reduce protocol overhead for frequent updates. Long polling can also deliver an event immediately when a request is already waiting. End-to-end latency still depends on routing, fan-out, buffering, and network conditions.
Does long polling scale better than WebSockets?
Neither is inherently more scalable for every workload. Long polling requires capacity for pending requests and repeated request processing; WebSockets require capacity for persistent connections and message handling. Compare concurrent clients, event frequency, batching, memory use, and infrastructure limits.
Can long polling be a fallback for WebSockets?
Yes, provided both transports share compatible subscription, authorization, and replay semantics. Use a cursor or event ID when switching so events during the transition can be recovered and deduplicated. Avoid leaving both transports active unintentionally, which can duplicate delivery and server work.