Real-time communication: polling, long polling, SSE, and WebSocket

01What does real-time communication mean?

Real-time communication in these interviews means delivering updates quickly enough for the product, such as chat messages appearing within a fraction of a second. It is not a hard real-time guarantee that every deadline is mathematically bounded. First name the acceptable delay and whether traffic is one-way or two-way.

The four common choices are short polling (repeat requests), long polling (hold one request until an update), server-sent events or SSE (keep a server-to-client HTTP event stream open), and WebSocket (exchange messages in both directions on one persistent channel). All still need authentication, reconnection, and a policy for missed updates.

A live update needs both a way to transmit messages and rules for storing, acknowledging, and recovering them. In this example, a receiving client has processed every message through ID 500 and saved that progress. We call 500 its last-applied cursor, the position from which it can safely resume. The server durably stores message 501 at 17:00:02. Compare how polling, long polling, SSE, and WebSocket deliver that new event; then handle reconnection independently of the transport.

An ordinary HTTP exchange begins when a client asks for something and ends when the server returns a response. The receiving client can request messages after 500, and the server can return an empty list if none exist yet. A later server event does not automatically produce another ordinary response after that exchange has finished.

HTTP requests can reuse an existing network connection; a new request does not always mean a new TCP or TLS setup. The central distinction in this lesson is the lifecycle of requests and application messages. Our timestamps, five-second polling interval, and client counts are explicit example assumptions, not measurements of a real messenger.

02Short polling: periodic requests and delay

With periodic Ajax polling, browser code repeats an HTTP request at a fixed interval. “Ajax” here means the page requests data asynchronously while remaining displayed; XML is not required. The receiving client asks at 17:00:00 and receives no new messages. Message 501 appears at 17:00:02, but its next scheduled request is at 17:00:05. The receiving client waits approximately three seconds plus network and processing time.

Polling is simple and fits modest update frequency or relaxed freshness requirements. At 100,000 clients polling every five seconds, even an idle service receives about 20,000 requests/second. Randomly arriving events wait about half an interval on average under a uniform-arrival assumption. Poll less often to reduce work, but accept more delay.

03Long polling: one held request per response

Long polling changes the empty-response behavior. The receiving client requests messages after 500 at 17:00:00. Instead of immediately returning an empty list, the server holds the request. At 17:00:02 it returns message 501. The receiving client then issues a new request after 501, leaving another question waiting for the next message.

The response is still an HTTP response to a client request. The server is not sending an unsolicited second response on a completed exchange. If no message arrives before the configured timeout, it returns or closes according to the API contract, and the client reissues the request.

This avoids frequent empty replies when messages are sparse, but it keeps many requests outstanding and repeats the request lifecycle after each result or timeout. A gap between responses and new requests can be handled by querying durable history after the last ID. Choose server and proxy timeout settings together so an intermediary does not unexpectedly cut every held request short.

04WebSocket: a persistent full-duplex message channel

WebSocket establishes a persistent channel carrying messages in both directions. In the standard HTTP/1.1 opening sequence, the receiving client sends an HTTP request asking to upgrade to WebSocket. A successful server response uses status 101 and the protocol’s required validation headers. After that handshake, the peers exchange WebSocket frames rather than ordinary HTTP response bodies for each chat message. RFC 6455.

At 17:00:02, the gateway sends frame 501 to the receiving client without waiting for a new application request. At 17:00:02.100, the receiving client can send a typing or acknowledgment message back over the same channel. This full-duplex behavior is useful for frequent two-way interaction.

The 101 upgrade is specific to the HTTP/1.1 handshake above. RFC 8441 defines extended CONNECT for WebSocket over HTTP/2, and RFC 9220 adapts it for HTTP/3. Client, gateway, and intermediary support must agree; do not assume every deployed WebSocket connection uses the same handshake.

The browser’s Origin header identifies the web page’s scheme, host and port. A WebSocket server can use it to restrict which web applications may initiate browser connections, which matters when browsers attach session cookies. This check answers a different question from which user is signed in.

Use encrypted transport and validate browser Origin according to the allowed application origins, especially for cookie-authenticated connections. Origin checking is an additional browser security boundary, not a substitute for authenticating the user or authorizing each subscription and command.

05Server-sent events: a server-to-client HTTP stream

Server-sent events, or SSE, use an HTTP response that remains open while the server sends text events. The response has content type text/event-stream. Browser EventSource understands the event format and reconnect behavior. At 17:00:02 the server can send an event containing ID 501 and the new message; IDs can support resumption. The stream is UTF-8 text, so binary payloads need another representation or delivery path. HTML standard.

The receiving client does not send chat commands backwards through that response stream. The receiving client can use a separate ordinary HTTP POST to send a message while receiving new events through SSE. That can be a clean design when most live traffic flows from server to client.

The server must preserve or reconstruct events after a reconnect; EventSource remembering an event ID does not create history storage. Intermediaries also need streaming-compatible behavior. If a proxy buffers the response until it is large, the apparent “live” messages can arrive late in batches.

An SSE event sends id: 501, then data: {"messageId":501,"text":"hello"}, followed by a blank line. Native EventSource remembers that ID and sends Last-Event-ID on reconnect. But receipt does not prove an asynchronous handler finished processing and saving the event. If recovery must resume after saved work, track that position separately in an application cursor. Pass it through an acknowledgment endpoint or an application-controlled reconnect, and make the replay API use it.

06Compare transports by traffic, latency, and direction

For frequent typing, acknowledgments, and chat traffic, choose WebSocket here. The benefit is a convenient two-way channel with less repeated request framing. The cost is gateway connection state, reconnect handling, and operational limits. For an export-progress display with occasional client commands, SSE may be simpler. For a status page tolerating several seconds of delay, polling may be entirely sufficient.

A persistent channel still consumes sockets, memory, heartbeat traffic, and network capacity. Estimate those separately from requests/second. Moving from polling changes the resource profile; it does not make idle clients free.

A heartbeat is a small periodic message used to check whether a connection or peer remains responsive. It adds traffic even when users are idle, and a missed heartbeat is evidence for a timeout policy rather than proof of a crash. Include this background work when comparing persistent channels with polling.

As a separate capacity estimate, 100,000 open connections at an assumed 16 KiB of total connection and bounded-buffer state consume about 1.53 GiB. One application heartbeat per connection every 30 seconds adds about 3,333 heartbeat messages/s in that direction. These are workload assumptions to measure on the chosen gateway, not protocol constants. They show why replacing 20,000 idle polls/s changes costs rather than eliminating them.

07Reconnect, replay, and slow-consumer recovery

Suppose the receiving client receives 501 and the connection drops before the receiving client records progress. On reconnect the receiving client reports its last applied ID, possibly still 500. The service replays 501 from durable history. The receiving client deduplicates by message ID so it appears once. The cursor should describe what the client actually applied, not merely bytes sent by a gateway.

If 500 is older than retained history, return an explicit resynchronization path and fetch a snapshot or current history page. Do not silently skip the missing interval. Use heartbeats to detect broken paths when needed, and stagger reconnect retries with randomized delays so every client does not reconnect simultaneously after an outage.

Bound each client’s outgoing buffer. A phone receiving more slowly than events arrive cannot accumulate memory forever. Disconnect and resume, reduce optional updates, or send a fresh summarized state according to the product contract. Authenticate connections and authorize subscriptions; an already-open connection must also have a policy for credential expiration or access revocation.

08Interview answer: choose a transport for chat

Interviewer: “Should this chat use WebSockets?”

Candidate: “Because our chat has frequent two-way activity, I would use a WebSocket channel after authenticating the connection. But I would separate transport from delivery correctness. The sending client’s 501 goes into durable history; the receiving client reconnects with its last applied ID and deduplicates any replay.

“If this were only server-driven progress, SSE plus ordinary command requests would be a reasonable simpler alternative. Polling would be acceptable if we could tolerate its freshness interval and the idle request load. I would also specify proxy timeouts and bounded per-client buffers, because a persistent connection can still fail or fall behind.”

The answer explains direction, latency, overhead, and recovery using the same event. It avoids claiming that WebSocket itself supplies offline history, authorization, ordering across all services, or exactly-once business effects.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.