WebSockets, SSE, or polling?

Polling is simplest and fine for low-frequency updates. SSE is one-way server-to-client over plain HTTP with built-in reconnect and Last-Event-ID, ideal for feeds, notifications, and token streaming. WebSockets are bidirectional and lowest latency, which chat, presence, and collaborative editing need.

How do you reconnect without hammering the server?

Exponential backoff with full jitter, capped at roughly 30 seconds, reset on a successful connection. Jitter is essential: without it, every client that dropped during an outage reconnects in lockstep and creates a thundering herd when the server comes back.

Why do you need heartbeats if TCP already detects failures?

TCP can take minutes to notice a dead peer, and proxies, load balancers, and mobile radios silently drop idle connections without a close frame. An application-level ping/pong on a short interval detects a zombie socket in seconds and triggers reconnect.

How do you guarantee message ordering and avoid duplicates?

Order by a server-assigned monotonic sequence or timestamp, never client clocks. Buffer out-of-order messages briefly, and if a sequence gap persists, fetch the missing range over REST. Deduplicate by having the client attach a unique message id that survives retries, so replays are idempotent.

What happens when the user goes offline?

Write outgoing messages to a durable outbox (IndexedDB) and render them as pending. On reconnect, flush the outbox in order with the same client ids so retries deduplicate server-side. Show explicit sending, sent, and failed states rather than pretending the message was delivered.

Real-Time & Offline Systems

Sockets are the easy part. Reconnects, ordering, duplicates, and offline are the interview.

Module 14 · Real-Time & Offline Systems

WebSockets, SSE, long polling and polling compared, plus reconnection with backoff, heartbeats, message ordering, deduplication, offline queues, and sync on reconnect.

Polling, long polling, SSE, and WebSockets compared, then the reliability layer: reconnection with backoff and jitter, heartbeats, message ordering, deduplication, gap-fill resync, offline outbox queues, and optimistic message states.

About this module

Choosing WebSockets is the easy half of a real-time answer. The half that earns the offer is what happens when the socket drops, the tab sleeps, messages arrive twice, or the user goes offline mid-send.

This module compares polling, long polling, SSE, and WebSockets, then works through the client-side reliability layer every chat and live dashboard needs.

You will learn exponential backoff with jitter on reconnect, heartbeat and ping/pong dead-connection detection, monotonic sequencing for ordering, idempotent client message IDs for deduplication, and gap-fill resync via a REST catch-up call.

It finishes with offline behavior: outbox queues, optimistic message states (sending, sent, failed), conflict handling, and how Service Workers and IndexedDB keep the UI usable without a network.

Phase 8 (Week 8) of the interview roadmap. Senior Track spans modules 1–19; the Staff Track starts at module 20.

Why this matters

Picking WebSockets is the easy half of a real-time answer. The half that earns the offer is what happens when the connection drops, the tab is backgrounded, a message arrives twice, or the user sends while offline. Interviewers probe exactly there.

Key topics covered

Transport Comparison
Polling & Long Polling
Server-Sent Events
WebSockets
Reconnection & Backoff
Heartbeats
Message Ordering
Deduplication
Gap-Fill Resync
Offline Outbox
Optimistic States
Chat Case Study

Where you'll use it

Designing a chat client that survives flaky mobile networks
Streaming live dashboard updates without a bidirectional socket
Detecting a dead connection that never fired a close event
Deduplicating messages after a reconnect replay
Queueing sends while offline and flushing them on reconnect

Real-Time Requirements

Clarify latency, direction, and volume before naming a transport.

“Use WebSockets” is the easy half of a real-time answer. The half that earns the offer is what happens when the connection drops, the tab sleeps for an hour, a message arrives twice, or the user hits send with no network.

Direction: server → client only, or genuinely bidirectional?
Latency budget: is 5 seconds fine, or do you need sub-second?
Volume: messages per second per client, and concurrent clients
Durability: may a message be lost, or must every one arrive exactly once?
Ordering: does out-of-order delivery corrupt the UI or just look odd?

Interview shortcut

Ask those five questions out loud. Half of real-time prompts do not actually need a socket, and recognizing that is a stronger signal than reaching for the heaviest tool.

Transport Comparison

Four options, and the one line that justifies each.

Real-time transport comparison
Transport	Direction	Auto-reconnect	Best for
Polling	Client pull	N/A	Low-frequency status checks
Long polling	Client pull, held open	Manual	Legacy fallback
SSE	Server → client	Built in	Feeds, notifications, token streams
WebSocket	Bidirectional	Manual	Chat, presence, collaboration

SSE is plain HTTP: it survives proxies, works with HTTP/2, and reconnects itself
SSE carries text only; WebSockets carry binary frames too
Browsers cap SSE connections per origin on HTTP/1.1 (about six)
WebSockets bypass normal HTTP caching, auth headers, and status codes
WebRTC data channels exist for peer-to-peer, but rarely appear in these rounds

Polling & Long Polling

Boring, cheap, and frequently correct.

Short polling: request on a timer; simplest thing that works
Long polling: server holds the request open until data or timeout
Back off when idle and pause entirely when the tab is hidden
ETag / If-None-Match turns an unchanged poll into a cheap 304
Cost scales with clients × frequency: state that number when justifying push

When polling wins

Order status, build progress, and background job results rarely need sub-second latency. Polling every few seconds avoids sticky sessions, connection limits, and a whole class of reconnect bugs.

Server-Sent Events

One-way streaming with reconnection and replay for free.

const es = new EventSource("/api/notifications");

es.addEventListener("message", (e) => {
  append(JSON.parse(e.data));
});

// The browser reconnects automatically and replays Last-Event-ID.
es.onerror = () => setConnectionState("reconnecting");

Each event may carry an id; on reconnect the browser sends Last-Event-ID
The server can then replay anything missed during the gap
retry: <ms> in the stream tells the browser how long to wait before reconnecting
EventSource cannot set custom headers: use cookies or a query token
Disable proxy buffering, or events sit in a buffer instead of reaching the client

WebSockets

Full duplex over one TCP connection, with none of the HTTP conveniences.

Opens with an HTTP Upgrade handshake, then leaves HTTP semantics behind
Authenticate at handshake time; re-authenticate on reconnect after token refresh
No status codes: define your own message envelope with a type field
Long-lived connections pin clients to servers: plan for sticky routing or a pub/sub bus
Backpressure is your problem: throttle or coalesce high-frequency updates before render

type Envelope =
  | { type: "message"; seq: number; clientId: string; body: string }
  | { type: "presence"; userId: string; online: boolean }
  | { type: "ping" }
  | { type: "pong" };

Reconnection & Backoff

Every long-lived connection dies. Plan the comeback.

let attempt = 0;

function connect() {
  const ws = new WebSocket(url);

  ws.onopen = () => {
    attempt = 0;              // reset only after a real open
    resubscribe();
    flushOutbox();
  };

  ws.onclose = () => {
    // Full jitter, capped at 30s, to avoid a thundering herd.
    const ceiling = Math.min(30_000, 500 * 2 ** attempt++);
    setTimeout(connect, Math.random() * ceiling);
  };
}

Exponential backoff with full jitter, capped around 30 seconds
Reset the attempt counter on successful open, not on the attempt itself
Reconnect immediately when the browser fires 'online' or the tab becomes visible
Re-subscribe to rooms and channels after every reconnect: server state is gone
Surface connection state in the UI so users know why nothing is updating

Heartbeats

The connection that looks open but is already dead.

TCP can take minutes to notice a vanished peer, and proxies, load balancers, and mobile radios routinely drop idle connections without sending a close frame. A ping/pong at the application level detects a zombie socket in seconds.

Client pings every ~25 seconds; expect a pong within a few seconds
Two missed pongs: treat as dead, close locally, and start reconnect
Keep the interval under the shortest idle timeout in your infrastructure
Heartbeats double as a liveness signal for presence indicators
Suspend heartbeats on hidden tabs to save battery, and resync on focus

Message Ordering

Order by server sequence, never by client clock.

The server assigns a monotonic sequence number per conversation or channel
Client clocks are unreliable: skewed, adjustable, and different per device
Buffer briefly on a gap; if seq 8 arrives before 7, wait a beat before rendering
If the gap persists past a short window, fetch the missing range over REST
Across a horizontally scaled backend, use a shared sequencer or Snowflake-style ids

Order does not equal delivery

A single WebSocket preserves order within itself, but a reconnect creates a new stream. Ordering guarantees only hold if the sequence is server-assigned and carried across connections.

Deduplication

At-least-once delivery means you will see the same message twice.

The client generates a stable id per message and reuses it on every retry
The server treats that id as an idempotency key: a repeat returns the original
The client keeps a recent-id set so replayed messages are dropped on render
Key list rendering by message id, never by array index
Reconciling: replace the optimistic entry when the server echo shares its client id

const seen = new Set<string>();

function onMessage(msg: Envelope) {
  if (msg.type !== "message") return;
  if (seen.has(msg.clientId)) return; // replay after reconnect
  seen.add(msg.clientId);
  appendMessage(msg);
}

Gap-Fill Resync

Reconnecting is not the same as catching up.

Record the highest sequence rendered before the connection dropped
On reconnect, request everything after it via a REST catch-up endpoint
Cap the replay window: past some threshold, refetch the view from scratch
Apply catch-up messages before live ones to avoid interleaving old and new
SSE gives a lighter version of this automatically via Last-Event-ID

async function resync(channelId: string, lastSeq: number) {
  const res = await fetch(`/api/channels/${channelId}/since?seq=${lastSeq}`);
  const { messages, truncated } = await res.json();

  if (truncated) return hardRefresh(channelId); // gap too large to patch
  messages.forEach(onMessage);
}

Offline Outbox

Sends made without a network must not silently vanish.

Write outgoing messages to IndexedDB before attempting to send
Render them immediately as pending so the user sees their own text
Flush the outbox in order on reconnect, reusing the original client ids
Cap retries per item and surface a failed state with a manual retry action
A Service Worker can serve the last cached view so the app opens offline

Why IndexedDB and not memory

Mobile browsers discard backgrounded tabs aggressively. An in-memory outbox loses the user’s unsent message when the OS reclaims the tab, which is precisely the moment they were offline.

Optimistic States

Show the message instantly, but be honest about its status.

Optimistic message states
State	Trigger	UI
Pending	Queued locally	Dimmed with a clock icon
Sent	Server ack received	Single tick
Delivered	Recipient ack	Double tick
Failed	Retries exhausted	Red marker with retry action

Reconcile by client id so the optimistic row becomes the real row in place
Never renumber or reorder on ack: that causes visible list jumps
Roll back explicitly on terminal failure rather than leaving a ghost entry
The same pattern covers likes, follows, and any low-risk mutation

Case Study: Chat

Slack or WhatsApp, in the shape an interviewer expects.

WebSocket (auth at handshake)
        ↕
   Connection manager
   backoff · heartbeat · resubscribe
        ↓
   Message pipeline
   dedupe by clientId → order by seq → gap-fill via REST
        ↓
   Message store (IndexedDB + in-memory)
        ↓
   Virtualized message list  ←  outbox (pending sends)

History loads over REST with cursor pagination; the socket carries only deltas
Virtualize the list: long conversations must not mount thousands of nodes
Typing indicators are throttled and ephemeral: never persist them
Presence is derived from heartbeats with a grace period, not from a single event
Unread counts come from the server so they agree across devices

Expected follow-up

“What if the user has 50 tabs open?” Share one connection across tabs using a SharedWorker or elect a leader tab via BroadcastChannel, then fan messages out locally.

Interview Takeaways

The reliability details that separate strong answers from transport trivia.

Clarify direction, latency, volume, durability, and ordering before choosing
SSE for one-way streams; WebSockets only when you truly need bidirectional
Reconnect with exponential backoff plus jitter, reset only on open
Heartbeats detect dead connections that never fired a close event
Order by server sequence; deduplicate by client-generated message id
Gap-fill over REST after reconnect, and hard-refresh if the gap is too large
Offline sends go to a durable outbox with explicit pending and failed states

Frequently Asked Questions

Real-time and offline systems interview questions.

Transport

Direction

Auto-reconnect

Best for

Polling

Client pull

N/A

Low-frequency status checks

Long polling

Client pull, held open

Manual

Legacy fallback

SSE

Server → client

Built in

Feeds, notifications, token streams

WebSocket

Bidirectional

Manual

Chat, presence, collaboration

const es = new EventSource("/api/notifications"); es.addEventListener("message", (e) => { append(JSON.parse(e.data)); }); // The browser reconnects automatically and replays Last-Event-ID. es.onerror = () => setConnectionState("reconnecting");

const seen = new Set<string>(); function onMessage(msg: Envelope) { if (msg.type !== "message") return; if (seen.has(msg.clientId)) return; // replay after reconnect seen.add(msg.clientId); appendMessage(msg); }

async function resync(channelId: string, lastSeq: number) { const res = await fetch(`/api/channels/${channelId}/since?seq=${lastSeq}`); const { messages, truncated } = await res.json(); if (truncated) return hardRefresh(channelId); // gap too large to patch messages.forEach(onMessage); }

State

Trigger

Pending

Queued locally

Dimmed with a clock icon

Sent

Server ack received

Single tick

Delivered

Recipient ack

Double tick

Failed

Retries exhausted

Red marker with retry action

WebSocket (auth at handshake) ↕ Connection manager backoff · heartbeat · resubscribe ↓ Message pipeline dedupe by clientId → order by seq → gap-fill via REST ↓ Message store (IndexedDB + in-memory) ↓ Virtualized message list ← outbox (pending sends)

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

Real-Time Requirements

Interview shortcut

Transport Comparison

Polling & Long Polling

When polling wins

Server-Sent Events

WebSockets

Reconnection & Backoff

Heartbeats

Message Ordering

Order does not equal delivery

Deduplication

Gap-Fill Resync

Offline Outbox

Why IndexedDB and not memory

Optimistic States

Case Study: Chat

Expected follow-up

Interview Takeaways

Frequently Asked Questions

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

Real-Time Requirements

Interview shortcut

Transport Comparison

Polling & Long Polling

When polling wins

Server-Sent Events

WebSockets

Reconnection & Backoff

Heartbeats

Message Ordering

Order does not equal delivery

Deduplication

Gap-Fill Resync

Offline Outbox

Why IndexedDB and not memory

Optimistic States

Case Study: Chat

Expected follow-up

Interview Takeaways

Frequently Asked Questions