Why real-time updates show up everywhere
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.
Poll · SSE · WS · WebRTC.
DB poll · hash · pub/sub.
L4/L7 · sticky · deploys.
Reconnect · celebrity · order.
The solution: two hops
- Hop 1 — Client↔server: How does the server deliver bytes to the browser/app? (polling, long poll, SSE, WebSocket, WebRTC)
- Hop 2 — Source→server: How does the right connection-holding machine learn that something changed? (DB pull, consistent hash ownership, pub/sub)
Networking 101 for realtime
Realtime interviews are networking interviews in disguise. Three layers matter most:
- L3 IP — packets, routing, best-effort (loss/reorder possible).
- L4 TCP / UDP — TCP: connection, ordered, reliable (handshake cost + state). UDP: fire-and-forget (WebRTC media often rides here).
- L7 HTTP / WS / WebRTC — application protocols on top of those transports.
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
| L4 | L7 | |
|---|---|---|
| Sees | IP:port / TCP | HTTP path, headers, cookies |
| TCP session | Client↔backend sticky | Terminates; new backend conn |
| Best for | WebSockets, raw performance | HTTP routing, API gateway-like |
| Realtime note | Natural for persistent sockets | Need explicit WS/SSE support |
Hop 1: client–server protocols
Simple polling — the baseline
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);- Pros — simple, stateless, works everywhere, fast to explain (saves interview time).
- Cons — latency up to interval + RTT; wasted requests; connection churn unless keep-alive.
- When — updates every few seconds OK; short-lived wait windows; realtime not the crux.
Long polling — easy near-realtime
Client requests; server holds until data (or timeout) then responds; client immediately re-requests. Feels push-like on plain HTTP.
- Pros — standard HTTP; easy; near-realtime for infrequent events.
- Cons — per-message callback latency; hanging requests confuse timeouts/monitors; browser connection limits per domain.
- When — payment status "tell me when done"; infrequent alerts; upgrade from simple poll with little infra change.
Server-Sent Events — efficient one-way
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));- Pros — built into browsers; auto-reconnect; better than long poll for frequent pushes; still HTTP.
- Cons — one-way only; some proxies buffer streams (opaque failure); connection limits; hanging-request monitoring.
- When — live dashboards, AI token streaming (ChatGPT-style), notifications outbound-only.
WebSockets — full-duplex champion
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).
- Pros — lowest overhead for frequent duplex; wide support.
- Cons — stateful; LB/sticky complexity; deploy churn; reconnect + missed-message recovery; hotspot connections.
- Infra — prefer L4 or WS-aware L7; "least connections" balancing; heartbeats for zombie detection.
WebRTC — peer-to-peer
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.
- When — video/audio calls, screen share, some collab presence (Canva cursors) / CRDT-friendly P2P Docs-like cases.
- Pros — low latency; lower server bandwidth.
- Cons — complex; STUN/TURN ops; setup delay; still sync home to mothership for durability.
Hop 2: server-side push / pull
Once clients hold connections on some machine, an event (new chat message) must reach that machine. Three patterns:
- Pull via polling — store events in DB; client polls; source and consumer decoupled; not true push.
- Push via consistent hashing — each user/doc owned by one server; route publishes to the owner.
- Push via pub/sub — Redis/Kafka topics; thin endpoint servers subscribe and forward.
Hop 2A — DB pull
Writers insert messages; readers SELECT … WHERE ts > ?. Simple; high latency; easy to forget poll QPS load on the DB.
Hop 2B — Consistent-hash ownership
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.
- When — Google Docs–style heavy in-memory doc state; expensive to rebuild on every machine.
- Scale event — dual-publish to old+new owners while draining connections; then flip membership.
- Vs pub/sub — if endpoints are thin forwarders, prefer pub/sub.
Hop 2C — Pub/Sub
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.
- Pros — easy horizontal scale of endpoints; state concentrated in pub/sub; <10ms typical hop.
- Cons — pub/sub SPOF/bottleneck (shard Redis/Kafka); many-to-many links; weaker presence unless you track connects explicitly.
- Interview — name Redis pub/sub or Kafka; shard by key; least-connections on WS tier.
When to use in interviews
| Scenario | Typical pick |
|---|---|
| Chat / typing / presence | WebSocket + pub/sub |
| Live comments (huge fan-out) | WS/SSE + hierarchical aggregation |
| Collaborative docs | WS + hash ownership + OT/CRDT |
| Dashboards / metrics | SSE or poll |
| AI token stream | SSE |
| Video call | WebRTC + signaling |
| Notification bell (seconds OK) | Simple polling |
Common deep dives
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.
In your interview
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."
Realtime scenario board
Cost and performance levers
Interview Q&A by level
Practice saying these out loud for realtime updates. Interviewers grade clarity and judgment more than buzzwords.
Match depth to the bar: define → trade off → operate. Don't dump principal answers in an entry-level screen.
Wrapping up
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.
How to answer this in a backend interview
Poll · SSE · WebSocket · push
Who multiplies messages — client count × events
Event bus → gateway → socket
TTLs and heartbeats, not eternal maps
Degrade to poll when sockets die
I'd choose the delivery channel from product needs: polling for rare updates, SSE for one-way server streams, WebSockets for bi-directional chat. The hard part is fan-out math — a goal event to millions of watchers needs a pub/sub or Kafka layer and gateway nodes that own socket connections. Presence uses heartbeats and TTLs. I'd plan auth on connect, backpressure, and a poll fallback so the design survives proxy timeouts.
Related Lattice posts: Networking essentials · Kafka · Redis · Design WhatsApp · Design news feed