Polling, long polling, WebSockets, and server-sent events

01Choose by direction and useful freshness

A report takes two minutes to run and updates progress every five seconds. The browser sends start and cancel commands, but most communication is progress travelling from the server to the browser. Ask who sends what and how soon it must appear before choosing the transport, the mechanism carrying the messages.

Ordinary polling repeats a status request:

1. The browser asks for progress every ten seconds.
2. The server returns the current status, even if nothing changed.
3. An update just after a poll waits nearly ten seconds for the next one; an update just before a poll waits almost none.
4. Under uniformly timed updates, the interval adds about five seconds of average detection delay. Network and processing time add more.

Polling is often enough when that delay is acceptable, but empty requests still consume work.

Long polling changes the waiting location:

1. The browser sends a status request.
2. The server holds it until an update or timeout.
3. The browser receives a response and sends the next request.

This avoids many repeated empty replies for sparse updates. Servers and proxies still retain waiting connection and request state. Efficient asynchronous handling need not dedicate an operating-system thread to each idle request; an implementation that does so can run out of threads.

02Compare the four mechanisms on one workload

For a persistent stream, compare message directions and operating costs.

• A WebSocket starts with a handshake, an opening exchange that establishes a channel for messages in both directions. Frequent player actions and game updates can justify that two-way channel.
• Server-sent events, or SSE, sends a server-to-browser text stream over HTTP. The browser’s EventSource API can reconnect and carry event identifiers. Start and cancel commands can use separate authenticated HTTP requests.
• A received event identifier is not automatically a durable record that the application applied that event. Both transports need application recovery rules.

Calculate load for 100,000 active viewers:

1. Ten-second polling produces 100000 / 10 = 10000 requests per second, assuming evenly spread polls and excluding retries.
2. A persistent design avoids those repeated cycles but retains roughly 100,000 client connections.
3. Budget each connection’s buffers, authentication state, and reconnect bursts. Measure the platform rather than assuming either option is universally cheaper.

Test the public path. A proxy may buffer SSE, close idle streams, or need WebSocket-upgrade support. Define authentication expiry, request limits, draining, and reconnection during replacement. A direct connection to the application does not verify those intermediaries.

03Recover the application, not merely the connection

Give one report’s updates stable version numbers, such as 11, 12, and 13, and retain the history needed for replay. The client saves a cursor: the last version it has applied.

Trace an interrupted delivery:

1. The server safely records version 12 and sends it.
2. The browser receives it, but disconnects before saving its new applied cursor.
3. It reconnects with saved cursor 11 and asks for later retained events.
4. Version 12 can arrive again. For progress, compare its version with the last applied version and avoid applying the same update twice. Save application state and the applied position together where a repeated effect would matter.

Opening the connection again does not recover history that no longer exists. If cursor 8 predates retained events starting at 12:

1. Detect the missing interval rather than report replay success.
2. Fetch an authorized current snapshot, for example report state at version 15.
3. Use that snapshot’s matching version as the new cursor.
4. Resume after 15. Keep changes such as version 16 available even if they occurred during the snapshot fetch, so the continuation has no new gap.

Connection byte order does not establish one application order across several producers or reconnects. Define the ordering scope required by the report.

A slow browser must not accumulate unlimited memory:

• For progress, combine replaceable intermediate percentages into the latest state if the product permits it.
• For a financial ledger, dropping transactions would be wrong; retain the required events or provide a precisely defined saved snapshot.
• Set a maximum queued-byte count per browser. If adding an event would exceed it, combine replaceable progress updates into the newest state or close that connection and let it resume from saved history. Do not silently drop the terminal result. Slowing intake or delivery when the consumer cannot keep up is backpressure.

SSE suits this mostly one-way report if the environment supports it. Polling may be simpler if its delay is acceptable. Whichever carries the bytes, permission, saved progress, replay, and duplicate handling make recovery correct.