Real-time updates for system design interviews

From Ticketmaster seat holds to WhatsApp messages to Google Docs keystrokes to ChatGPT token streams — users expect to see changes the moment they happen. Standard HTTP request/response closes after each exchange. That model breaks when the server must speak first.

Many candidates (even with 10+ years) never built the push path themselves — a specialized team did it once. Interviews still expect you to choose protocols and fan-out wisely. This post is that bridge. Pair with Networking essentials and the short version in Common patterns.

Realtime interviews are networking interviews in disguise. Three layers matter most:

HTTP request lifecycle (why connections matter)

DNS → TCP 3-way handshake (SYN / SYN-ACK / ACK) → HTTP request/response → TCP teardown (FIN/ACK). Each RTT adds latency; each connection is state both sides maintain. HTTP keep-alive amortizes setup across polls — critical if you stay on polling.

L4 vs L7 load balancers

Client GET /updates on an interval. Not "true" realtime — often good enough. Chat: "messages since cursor X every 2s."

async function poll() {
  const res = await fetch('/api/updates?since=' + cursor);
  const data = await res.json();
  processData(data);
}
setInterval(poll, 2000);

Client requests; server holds until data (or timeout) then responds; client immediately re-requests. Feels push-like on plain HTTP.

HTTP response with Content-Type: text/event-stream and chunked transfer. Server writes many data: frames on one connection. Browser EventSource auto-reconnects; Last-Event-ID fills gaps.

const es = new EventSource('/api/updates');
es.onmessage = (e) => updateUI(JSON.parse(e.data));

HTTP upgrade to a persistent bidirectional channel. Opaque messages (JSON/Protobuf). Best when high-frequency reads and writes share one pipe (chat, typing, cursors, multiplayer).

Direct browser-to-browser media/data after signaling (often via WebSocket/SSE). NAT traversal: STUN (hole punching) and TURN (relay fallback). Signaling itself is a mini realtime system.

Once clients hold connections on some machine, an event (new chat message) must reach that machine. Three patterns:

Writers insert messages; readers SELECT … WHERE ts > ?. Simple; high latency; easy to forget poll QPS load on the DB.

Modulo user_id % N works until N changes (almost everyone remaps). Consistent hashing + virtual nodes minimizes moves. Coordination via ZooKeeper/etcd for membership. Clients connect randomly then redirect, or discover the owner.

Client hits any endpoint (least-connections LB) → endpoint subscribes to user:{id} (or room topic) → publishers write the topic → all subscribed endpoints forward on the local socket map.

Connection failures & reconnect

Mobile networks die silently (zombie sockets). Heartbeats detect death. Track last sequence / Redis Stream ID; on reconnect, replay missed events. Exponential backoff + jitter to avoid reconnect storms after deploys.

Celebrity / mega fan-out

1 celebrity → millions of sockets. Don't write one message into a million personal queues synchronously. Cache once; hierarchical regional fan-out; batch; see Scaling writes.

Ordering

For product interviews, funnel a room/auction/doc through one partition or owner and stamp order there. Vector clocks are deep infra — mention only if asked.

Collab conflicts

Getting bytes there fast ≠ correct merge. OT or CRDTs for Docs-like editing — separate from the transport choice.

What to say out loud

"Realtime is two hops. For hop 1 I'll start with polling unless we need sub-second push — then SSE for one-way or WebSockets for duplex, with an L4 or WS gateway so the rest stays stateless. For hop 2 I'll use Redis/Kafka pub/sub unless each connection owns heavy state like a Docs session — then consistent-hash ownership with coordinated drain on scale. Clients resume with sequence IDs; heartbeats kill zombies; celebrities get hierarchical fan-out."

Practice saying these out loud for realtime updates. Interviewers grade clarity and judgment more than buzzwords.

Real-time systems pair a delivery protocol with a fan-out trigger. Start simple, escalate with evidence, and keep socket state from infecting your whole architecture. Continue with Common patterns, Networking essentials, Message queues, Kafka, Redis, and Consistent hashing.