Real-time delivery: polling, SSE and WebSocket

Start with who needs to speak, then choose how much connection state the network and client can keep.

Before you read: predict

A checkout administrator's live console receives payment-authorization changes several times a second. Its Pause action must travel on the same already-open connection, and the gateway accepts an HTTP upgrade.

Which channel is the best fit for that session?

The 30-second version

Choose a channel that matches the arrows. Short polling asks repeatedly for a snapshot. Long polling holds one request until an update. SSE keeps a server-to-page event stream and resumes from an event id. WebSocket lets both peers send independently. After a close, reconnect on a fresh channel, then send an application cursor if the product supports it.

Start with who needs to speak, then choose how much connection state the network and client can keep.

How it works

Step 1 of 9

Draw the arrows. A page asking only for latest state can use HTTP; its response is a snapshot, not a standing conversation.

Analogy: The mailbox, radio and telephone on the desk

A clerk checks a mailbox at intervals for the newest status card, listens to a desk radio that only broadcasts outward, or uses a telephone where either caller can speak. A dropped telephone call is over; placing a new call restores the line, while the clerk separately explains which card was last handled.

On the desk	In the browser client
clerk checks the mailbox every scheduled round	short polling (step 2)
clerk leaves one collection slip until a new card arrives	long polling (step 3)
desk radio broadcasts a status bulletin	SSE server-to-page events (steps 4–5)
telephone callers speak in either direction	WebSocket duplex messages (step 6)
a new telephone call begins after the old one ends	reconnect plus an application resume cursor (step 7)

Breaks down when: the objects make broadcasts look durable. A real SSE or WebSocket connection does not by itself store an event history or guarantee one delivery; the application must define that policy (step 8).

It deliberately stops before operational fan-out and broker scaling.

Examples, run for real

4.1 Checkout-event stream

It observes two event ids and two messages. This is an executable illustration of stream framing, not an answer to a served item.

Cross-domain contrast — ExamHall EXH-1960. An invigilator page can receive a server event feed while its candidate timer remains a separate product concern. This named case is explanatory only; the graded proof domain remains checkout.

example SSE headers content-type=text/event-stream · event ids 14,15 · messages price-locked,stock-held

4.2 Transport decision board

Surface	Who initiates updates?	Channel	Boundary
seller inventory overview	page asks at a tolerable cadence	short polling	the view can be stale between checks
carrier-status wait	server completes one pending request	long polling	a successor request begins after completion
merchant stock notice	server publishes to the page	SSE	the feed has no history by itself
warehouse scanner session	page and service exchange scan frames	WebSocket	a reconnect needs a new channel

This table is a selection aid, not a delivery guarantee. RFC 6455 says a WebSocket is a two-way channel; HTML defines EventSource reconnection and last-event handling. The product still chooses missed-message policy. RFC 6455, HTML SSE

Picture it

Concept illustration for this lesson. — An illustration to help it stick. The mechanism is in the sections above.

Try it

Answer first, then check. Nothing is saved.

Question 1 of 5

The status endpoint keeps a request whose after cursor has no later event pending. The first request is accepted before authorized enters the event log; the next request is accepted before captured enters it. The page runs:

Which trace results?

let after = 0;while (shown.length < 2) {  const event = await status(after);  shown.push(event.state); after = event.id;}

Question 2 of 5

A browser EventSource receives checkout notices with id:1 and id:2, then the connection ends. The server retains notices 1, 2 and 3 and uses this reconnect query.

Which request-header and received-id trace results?

const after = Number(request.headers['last-event-id'] ?? 0);const batch = log.filter(event => event.id > after);

Question 3 of 5

A risk badge's status changes a few times a day, and each scheduled check must show the status current at that check. The existing edge proxy stores upstream response bytes until the upstream response ends; the team cannot alter it. Behind it, the origin serves /status (the current status), /long-poll (answers at the next status change) and /stream (an event stream that stays open). Here get reads a completed response body, render changes the badge, and onCheck registers the scheduled handler.

Which code keeps the badge correct at each check?

Question 4 of 5

A checkout admin page displays needs-approval from its existing event feed. The control must record one gateway state change.

Which handler request should it issue?

Question 5 of 5

An inventory-reservation WebSocket closes while its pending ledger contains { id: 'op-7', action: 'pause' }. The wire format is action:id, and encode serializes a ledger entry into it. connect() constructs a new WebSocket to the gateway, and opened(socket) resolves on that socket's open event. The operator presses Resume.

Which handler lets the gateway process that pending operation?

Go deeper

Pro tip

Add the actual network path to the sketch, including proxies that buffer or end a response. It prevents a protocol choice from assuming behavior the path does not supply. When: before committing a live-update design. Status: practice heuristic; not a delivery or readiness claim.

Source

It supports the two-way channel, HTTP polling comparison, independent sends and reconnect-backoff guidance. Valid as of 2026-09-30.
WHATWG HTML Living Standard, Server-sent events, §§9.2.1–9.2.4: https://html.spec.whatwg.org/multipage/server-sent-events.html · fetched 2026-09-30 and saved as sources/html-sse.txt (SHA-256 recorded in the file). It supports event-stream reconnecting, EventSource states, last event ID and the Last-Event-ID header. Valid as of 2026-09-30.
MDN, EventSource: https://developer.mozilla.org/en-US/docs/Web/API/EventSource · directly fetched 2026-09-30 and saved as sources/mdn-eventsource.txt, with its body hash and retrieval path. The explicit one-way communication passage refutes the reverse-channel distractor.

Checked against the tools and docs as of 2026-09-30.

Predict first