Polling, SSE and WebSockets

Why it matters

HTTP waits to be asked. Live scores and chat need the server to speak first.

Pick a technique

Start with plain . Move only when users notice the delay, or the request count hurts.

Technique	Direction	Use it when	At 100K clients
Short polling	Client asks	Seconds of delay are fine	20,000 req/s at 5 s, 3,333 req/s at 30 s
Long polling	Client asks, server holds	Near real time, but streaming is blocked	3,333 req/s idle (30 s timeout), one held request each
SSE	Server to client	The server talks, the client rarely does	100K open streams: 2 nodes at 50K each, plus headroom
WebSocket	Both ways	The client sends often too	100K sockets, plus a pub/sub backplane
Webhook	Server to server	An outside system tells you	Costs nothing while idle

Product	Pick	Why
Sales dashboard	Poll every 30 s	Seconds of delay are fine
Order or score alerts	SSE	Server talks, client listens
Chat	WebSocket	Both sides send often
Live cursors	WebSocket	Many tiny messages both ways

Technique	HTTP requests	Empty answers	Avg delay	Worst delay
Short polling (5 s)	12	7	1.90 s	3.07 s
Long polling	6	1	50 ms	50 ms
Server-Sent Events	1 (stream)	0	50 ms	50 ms
WebSocket	1 (upgrade)	0	50 ms	50 ms

Polling and SSE

Short is a timer and a fetch.

WebSockets and the connection tier

A starts as an HTTP request, then upgrades the same connection into a two-way channel of small messages.

Webhooks

Stripe and GitHub POST to your endpoint when something happens, sometimes twice, and retry until you answer 2xx.

What goes wrong

Real-time systems fail at the edges: when many clients drop together, when a middlebox interferes, and when a gap opens between two events.

Failure	Scene	Fix
Reconnect storm	A node dies and 50K clients return in one second	Full jitter, wider first window
Proxy buffering	The SSE feed freezes behind nginx	Disable buffering, ping every 15 s
Lost events	A 6 s drop skips two messages	Ids, a log, resume by last id
Slow consumer	One phone on a bad network	Cap its queue, then drop or close

Code

Short polling

short-polling.js

// Short polling that pauses while the tab is hidden (the source polled forever)
export function startPolling(fn, ms = 5_000) {
  let timer, stopped = false;
  const tick = async () => {
    if (!document.hidden) await fn().catch(() => {});   // one failed poll shouldn't end polling
    if (!stopped) timer = setTimeout(tick, ms);          // schedule after the reply, so polls never overlap
  };
  tick();
  return () => { stopped = true; clearTimeout(timer); };   // also stops a poll that is still in flight
}

Long polling: client

long-poll-client.js

import { backoffDelay } from './backoff.js';

// Long polling client. The source re-polled instantly on errors, so a down server caused a tight loop.
export async function longPoll(onEvents, signal) {
  let since = 0, failures = 0;
  while (!signal.aborted) {
    try {
      const r = await fetch(`/events?since=${since}`, { signal: AbortSignal.any([signal, AbortSignal.timeout(35_000)]) });
      if (r.status === 204) continue;                         // the server waited 30 s with no news: ask again
      if (!r.ok) throw new Error(`HTTP ${r.status}`);
      const { events, cursor } = await r.json();
      since = cursor; failures = 0;
      onEvents(events);
    } catch {
      if (signal.aborted) return;
      failures++;
      await new Promise(res => setTimeout(res, backoffDelay(failures)));   // 0–2 s, 0–4 s, … capped at 30 s
    }
  }
}

Long polling: server

long-poll-server.js

// Long polling server: subscribe first, then read the backlog, so no event slips through the gap.
app.get('/events', async (req, res) => {
  const since = Number(req.query.since ?? 0);
  let done = false, early = [];                               // live events that arrive while the backlog loads
  const finish = events => {
    if (done) return;
    done = true;
    clearTimeout(timer);
    unsubscribe();
    if (!events) return;                                      // the client went away: just clean up
    if (!events.length) return res.sendStatus(204);           // no news in 30 s: the client asks again
    res.json({ events, cursor: events.at(-1).id });
  };
  const unsubscribe = bus.subscribe(ev => (early ? early.push(ev) : finish([ev])));   // 1. subscribe…
  const timer = setTimeout(() => finish([]), 30_000);
  res.on('close', () => finish());                            // res, not req: req 'close' fires once the request is read

  const backlog = await eventsAfter(since);                   // 2. …then read what was missed
  const last = backlog.at(-1)?.id ?? since;
  const events = [...backlog, ...early.filter(ev => ev.id > last)];   // an event in both lists is sent once
  early = null;                                               // from now on, answer with the next live event
  if (events.length) finish(events);
});

Server-Sent Events

sse.js

// SSE server with resume (Last-Event-ID) and heartbeats (the source had neither)
app.get('/stream', async (req, res) => {
  res.set({ 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache', 'X-Accel-Buffering': 'no' });  // nginx: don't buffer
  res.flushHeaders();
  res.write(`retry: ${2_000 + Math.floor(Math.random() * 3_000)}\n\n`);   // reconnect delay, jittered per client

  let lastId = Number(req.get('Last-Event-ID') ?? 0);         // EventSource sends it on every reconnect
  const send = ev => {
    if (ev.id <= lastId) return;                              // already sent: replay and live can overlap
    lastId = ev.id;
    res.write(`id: ${ev.id}\nevent: ${ev.type}\ndata: ${JSON.stringify(ev.data)}\n\n`);
  };
  let pending = [];                                           // live events that arrive during the replay
  const unsubscribe = bus.subscribe(ev => (pending ? pending.push(ev) : send(ev)));   // subscribe first…
  const ping = setInterval(() => res.write(': ping\n\n'), 15_000);   // comment lines keep idle proxies open
  res.on('close', () => { clearInterval(ping); unsubscribe(); });

  (await eventsAfter(lastId)).forEach(send);                  // …replay what was missed while disconnected…
  pending.forEach(send);                                      // …then what arrived meanwhile
  pending = null;                                             // from now on, go live
});

// Browser: EventSource reconnects by itself and sends Last-Event-ID automatically
const es = new EventSource('/stream');
es.addEventListener('score', e => renderScore(JSON.parse(e.data)));

WebSocket heartbeat

ws-heartbeat.js

// Server heartbeat: ping every 30 s and drop peers that didn't answer the previous ping
wss.on('connection', ws => {
  ws.isAlive = true;
  ws.on('pong', () => { ws.isAlive = true; });
  ws.on('message', m => broadcast(m));
});

setInterval(() => {
  wss.clients.forEach(c => {
    if (!c.isAlive) return c.terminate();          // no pong in 30 s: laptop asleep, NAT entry gone, cable pulled
    c.isAlive = false;
    c.ping();
  });
}, 30_000);                                        // shorter than proxy/LB idle timeouts (often 60 s)

WebSocket client with reconnect

import { backoffDelay } from './backoff.js';

// WebSocket client with reconnect + full jitter, so 100K clients don't all reconnect in the same second after a deploy
export function connect(url, onMessage) {
  let ws, timer, attempt = 0, closed = false;
  const open = () => {
    ws = new WebSocket(url);
    ws.onopen = () => { attempt = 0; };
    ws.onmessage = e => onMessage(JSON.parse(e.data));
    ws.onclose = () => {
      if (closed) return;
      timer = setTimeout(open, backoffDelay(attempt++, { baseMs: 500 }));   // 0–0.5 s, 0–1 s, 0–2 s, … up to 30 s
    };
  };
  open();
  return {
    send: data => ws.readyState === WebSocket.OPEN && ws.send(JSON.stringify(data)),   // false while reconnecting
    close: () => { closed = true; clearTimeout(timer); ws.close(); },                 // also cancels a pending reconnect
  };
}

Scaling Socket.IO across nodes

socketio-redis.js

// Scaling Socket.IO across nodes: the Redis adapter relays room broadcasts between servers
import { Server } from 'socket.io';
import { createAdapter } from '@socket.io/redis-adapter';
import { createClient } from 'redis';

const pub = createClient({ url: process.env.REDIS_URL }), sub = pub.duplicate();
await Promise.all([pub.connect(), sub.connect()]);
const io = new Server(httpServer, { adapter: createAdapter(pub, sub) });

io.use(async (socket, next) => {                                   // authenticate before accepting the socket
  try {
    socket.data.userId = await verifyToken(socket.handshake.auth.token);
    next();
  } catch {
    next(new Error('unauthorized'));
  }
});

io.on('connection', socket => {
  socket.join(`user:${socket.data.userId}`);                       // one room per user: all their devices join it
  socket.on('chat', msg => io.to(`user:${msg.to}`).emit('chat', msg));   // reaches the user on any node
});

Verifying webhooks

Real-time delivery in the interview

Bring this up the moment a requirement says live, instant, or notify, and say the cheapest option that meets the delay.

If the interviewer says	You raise
"Live sports scores for millions"	SSE, fan-out through pub/sub, resume with Last-Event-ID
"Chat or collaborative editing"	WebSockets with ids, a pub/sub backplane and a log
"A dashboard that updates"	Poll every 30 s, add a 304
"A payment provider tells us"	A webhook with signature check, queue and reconcile job
"What if a server restarts?"	Drain, jittered reconnect, resume by last id

Interview questions

Live sports scores: which technique?

: one-way, plain HTTP, and it resumes with Last-Event-ID. through .

Why does SSE hang behind some proxies?

The proxy buffers the stream. Disable buffering and send : ping .

How do you serve 1M concurrent WebSockets?

At ~50K sockets per node, about 20 nodes plus headroom. Route over pub/sub, and drain on deploy.

SSE or WebSocket for a chat app?

Usually , since messages flow both ways. Give messages ids so clients can resume.

How do you avoid losing messages when a socket drops?

Give every message an id and append it to a log first. The client sends its last id on reconnect and the server replays the gap. by id.

Do WebSockets need sticky sessions?

Not once connected: the socket is one connection. Only long-poll fallbacks and in-memory state need stickiness. Keep state in instead.

How do you notify a mobile user whose app is in the background?

Use push (APNs or FCM), since the OS kills background sockets. On open, reconnect and sync.

Check yourself

Question 1 of 5

Score 2 out of 3 or better to mark this page complete.

1. You need one-way server-to-browser updates with automatic resume after a dropped connection. Which technique?SSEWebSocketShort polling

Trade-offs

Bring it up before they ask

Why it matters

Pick a technique

Polling race

Polling and SSE

WebSockets and the connection tier

Webhooks

What goes wrong

Code

Short polling

Long polling: client

Long polling: server

Server-Sent Events

WebSocket heartbeat

WebSocket client with reconnect

Scaling Socket.IO across nodes

Verifying webhooks

Real-time delivery in the interview

Ask how fresh and in which direction

Default to polling, upgrade with a number

Pick SSE or WebSocket by direction

Scale the connection tier

Own the failure modes

Interview questions

Check yourself

Deep dives