Real-time Updates

Real-time is a freshness requirement, not a transport name. A job-status page may tolerate a few seconds, while a collaborative cursor needs much faster feedback. First define how quickly a change must become visible and what happens after disconnection. Then select a transport and recovery protocol that can meet that contract.

Learning goals

Polling; long polling; SSE; WebSockets; connection lifecycle; event IDs; resumption; heartbeat; backpressure; authentication expiry.

The mechanism at a glance

Figure — Durable change → Event history (append); Event history → Gateway (stream); Gateway → Client apply (event ID); Client apply → Cursor store (after apply); Cursor store → Event history (resume); Snapshot API → Client apply (reset if expired)

The numbered components identify responsibilities. Follow the labeled arrows rather than treating the numbers as a global execution order. The scenario later in this lesson shows one concrete sequence.

Step-by-step reasoning

1. Choose the simplest transport

Polling asks for current state at intervals and is easy to operate for infrequent changes. Long polling holds a request until data or a timeout is available. SSE provides a server-to-client event stream over HTTP. WebSockets support bidirectional messages. The transport does not decide durability, ordering, or whether an application event was applied.

2. Give events identity and scope

Attach stable event IDs and a cursor in the ordering scope the product needs. A cursor might be per room, user, or job. Store enough history to support the intended reconnect horizon. If a client needs only the latest status, a snapshot plus version can be simpler than replaying every intermediate update.

3. Make reconnection ordinary

Networks change, proxies close idle connections, and deployments restart gateways. Send heartbeats where useful, reconnect with backoff and jitter, and resume after the last applied cursor. Deduplicate overlap between replay and live events. If the cursor is too old, request a fresh snapshot and establish a new baseline.

4. Bound every connection

Cap buffers and message size, enforce authentication and authorization, and define behavior when credentials expire. A slow consumer should not grow unbounded server memory. Drop replaceable updates such as cursor positions if the product permits it, but do not silently drop durable chat messages. Monitor reconnect rate, buffer pressure, and end-to-end event age.

Contracts and state

The following sketch makes the decision boundary concrete. Field names and capacity assumptions are illustrative; adapt them to the stated product contract.

Event envelope
{ id: "e_901", stream: "job_42", version: 17,
  type: "progress", payload: {percent: 60} }
Resume request: after=e_901
Expired cursor response: reset_required + snapshot_version

Worked example

For an export job, polling every five seconds may satisfy the product. For live comments, SSE plus cursor replay can deliver server-originated updates without a bidirectional protocol. For collaborative editing, bidirectional transport is useful, but conflict resolution still needs an application protocol. Do not claim WebSockets solve concurrent editing merely because both sides can send messages.

Failure walkthrough

A gateway sends an update and the connection drops before an application acknowledgment. The server cannot infer that the user saw it. Retain or reconstruct the event, replay on reconnect, and let the client deduplicate. A TCP acknowledgment confirms transport progress, not that application state was rendered or durably recorded.

Figure — Apply event 17 → Persist cursor 17 → Connection drops → Resume after 17 → Replay or reset explicitly

Decisions and trade-offs

Check your understanding

Which events can a collaborative UI safely replace with only their newest value?

Transfer to a new scenario

Compare transport choices for job status, live comments, and collaborative edits.

Does an open socket prove that a particular event reached the user?

Continue the connection

Study Networking Essentials and explain which guarantee from this lesson carries into that topic.

Reconnect without a gap

Choose polling for infrequent updates, SSE for a server-to-browser stream, and WebSockets for bidirectional exchange. Transport selection does not define durability or ordering. Persist important events with a monotonic position in the relevant stream and let a client resume from the last durable position it processed.

To bridge history and live updates, obtain a high-water mark or subscribe while fetching history, then deduplicate the overlap. Fetching old events and only afterward subscribing can miss events published between those operations. A retained-history limit requires a full snapshot reset path when the cursor is too old.

Each client needs a bounded output buffer. Slow clients can receive coalesced state, a reset instruction or a disconnect according to the product contract. Never let one browser retain unbounded server memory. Presence and typing indicators can be ephemeral while messages or financial status updates use durable replay.

Figure — A decision worksheet for Real-time Updates: read the mechanism and its guarantee together.

Operational sketch

client resumes after sequence 120
server establishes high-water mark 150
replay 121..150; buffer newer events
then stream 151 onward; dedup by event ID

A tempting mistake

A load balancer reconnecting a socket to another host must not lose the user’s durable cursor. Sticky sessions improve locality but are not a recovery strategy.

Transfer exercise

What happens when the requested cursor predates retained history?