API design

Long polling vs WebSockets

API designReal-time systemsDecision guide

Short answer

Use long polling when updates are infrequent and compatibility with ordinary HTTP infrastructure is the priority. Use WebSockets when clients and servers exchange messages continuously or latency and connection efficiency justify explicit connection lifecycle management.

Written and reviewed by Sahil Srivastav

What each one actually is

Long polling sends an HTTP request that the server holds until an event, timeout, or cancellation, then the client immediately opens the next request. It is easy to deploy but each cycle has request and reconnect overhead.

WebSockets upgrade once and keep a bidirectional channel. They reduce repeated HTTP setup for active conversations, but require heartbeat, backpressure, authentication refresh, and drain handling.

Both need a missed-event strategy. Return a cursor or sequence so a timeout, reconnect, or proxy close does not silently skip updates.

Side by side

	Long polling	WebSockets
Connection model	Repeated held HTTP requests	Persistent upgraded connection
Direction	Server response, then client request	Both sides at any time
Infrastructure	Broad HTTP compatibility	Upgrade and idle timeout support
Latency	Request and reconnect overhead	Low after connection establishment
Idle resource	Request slots and timers	Open connection and buffers
Client complexity	Retry request loop	Stateful socket lifecycle
Scale pattern	Polling fleet and held requests	Connection count and fan-out broker
Failure recovery	Retry with cursor	Reconnect with cursor and resubscribe

Choose Long polling when

The event rate is low and ordinary HTTP is the strongest compatibility requirement
Ingress, proxies, or server frameworks cannot support upgrades reliably
The client can tolerate a small request boundary per event
A simple cursor-based retry loop is easier to operate

Choose WebSockets when

Events or commands are frequent and interactive
Both directions need prompt delivery
Connection overhead dominates long-polling cost
The team can operate heartbeats, limits, and graceful draining

The trade-off in detail

Long polling can consume a server worker or connection while waiting unless the runtime is designed for asynchronous I/O. Set a maximum hold time and jittered reconnects so a fleet does not reconnect in lockstep.

WebSockets concentrate many logical messages into long-lived sessions. A proxy restart can disconnect thousands of clients at once, so reconnect storms need backoff and admission control.

Neither transport supplies durable delivery. Store a sequence and let clients resume from it; otherwise “real time” becomes “best effort while connected.”

Things that are commonly said and are wrong

“Long polling is normal polling.” The server waits for new work, so it avoids empty responses but still has request lifecycle overhead.
“WebSockets always use less capacity.” A quiet socket is cheap per message but expensive in connection count and gateway memory.
“A successful connection means the client is subscribed.” Subscription authorization, routing, and replay still need application state.

Decide it in a real repository

Choosing correctly on a whiteboard and enforcing the choice in code are different skills. Gronex ships broken backend repositories whose tests assert the invariant, not the happy path.

FAQ

Which is easier behind a corporate proxy?

Long polling usually has fewer upgrade requirements because it is ordinary HTTP. Test hold timeouts and intermediary buffering; compatibility still depends on deployment.

Can long polling deliver events in order?

It can if the server returns a cursor and the client acknowledges or resumes from it. Avoid relying on timing alone when multiple requests overlap.

When should I migrate to WebSockets?

When event frequency, bidirectional interaction, or request overhead is measurable enough to justify connection lifecycle and infrastructure work.