The polling problem

Polling is "ask the server every N seconds: anything new?"

setInterval(() => fetch('/api/messages').then(applyDelta), 3000);

Costs per poll, even when nothing changed:

• Full HTTP request: headers (~500B–2KB with auth/cookies), TCP/TLS overhead on cold connections, server-side auth + DB query.
• Battery drain on mobile (radio wake-up per poll).
• Worst-case latency = poll interval (3s means up to 3s lag).
• At scale: 10k users × 1 req/3s = 3,333 req/s sustained for zero new data.

Aggressive polling (1s or faster) multiplies all of that. Engineers reach for it because it's easy; ops pays the bill in CPU, bandwidth, and DB load.

WebSockets

A WS connection is established once via HTTP Upgrade handshake, then becomes a persistent TCP socket carrying framed messages in both directions:

const ws = new WebSocket('wss://example.com/feed');
ws.onmessage = e => applyMessage(JSON.parse(e.data));
ws.send(JSON.stringify({ type: 'subscribe', room: 'channel-42' }));

Properties:

• Server push: the server sends a frame the instant something changes. Latency ≈ network RTT, not poll interval.
• Tiny frames: ~2–14 bytes of framing overhead per message vs ~500B–2KB of HTTP headers.
• Full-duplex: client and server can send independently.
• One handshake: TCP + TLS + Upgrade once, then free.

When to pick which

Server-Sent Events (SSE)

The often-forgotten middle ground. Standard HTTP, one-way server → client, auto-reconnect built in:

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

Cheaper to operate than WS (it's just HTTP) and works through most corporate proxies. Pick SSE when you don't need client→server messages.

Long polling — the fallback

Client opens a request; server holds it open until it has data or a timeout (~30s), then responds; client immediately reopens. Mimics push over HTTP. Useful where WS is blocked (some enterprise proxies), but stateful, hard to scale, and largely obsolete.

Operating WebSockets in production

The hard parts aren't the API — they're operations:

• Reconnection: connections die (mobile network changes, proxy timeouts). Implement exp-backoff reconnect + a resume token / last-event-id for missed messages.
• Backpressure: a slow client can fill the server's send buffer. Drop or throttle.
• Horizontal scaling: WS is stateful (the user is "on" server N). You need a pub/sub bus (Redis, NATS) so a message published on server A reaches a subscriber on server B.
• Idle timeouts: load balancers (AWS ALB default 60s, Cloudflare ~100s) close idle sockets. Send ping frames every ~30s.
• Auth: the initial handshake is HTTP, so cookies / JWT work. Reauth on token expiry is application-level.
• Cost: persistent connections cost memory. ~10k connections per modern node is comfortable; tune ulimit + kernel.

When polling IS the right answer

• Data changes slowly and infrequently (status pages refreshed every minute).
• The client only cares "the next time I look," not "the moment it changes."
• The infrastructure can't host WS (cheap static hosting + plain HTTP API).
• Simplicity matters more than latency.

The case against is aggressive polling — 1s/2s intervals against APIs serving thousands of users. That's the antipattern. Once-a-minute polling for a low-stakes signal is fine.