WebSockets

A protocol that upgrades an HTTP connection to a persistent, bidirectional, full-duplex channel over one TCP connection. It's the workhorse for realtime apps (chat, live updates). Server can push without client polling.

When to use

Bidirectional realtime (chat, multiplayer, collab editing).
High-frequency server→client push.

When not to

One-way server push where SSE is simpler.
Infrequent updates where polling or webhooks suffice.

Definition

WebSocket starts as an HTTP Upgrade handshake, then the connection speaks a framed message protocol bidirectionally until closed. Messages can be text or binary. It keeps one TCP connection alive for low-latency two-way traffic.

Why it exists

HTTP is request/response; pushing server updates required polling or hacks. WebSockets give a real bidirectional channel with low overhead, ideal for chat, gaming, and live dashboards.

How it works

Client opens WS to ws:// or wss://, server accepts the upgrade, then both send framed messages. Often a pub/sub broker (Redis) fans messages across many server instances holding connections. Heartbeats (ping/pong) keep the connection alive through proxies.

Scaling limits

Each connection holds server memory and a file descriptor; millions of connections need connection-draining, sharding by user, and a fan-out broker. Stateful connections break horizontal LB (must pin a user to a node).

Cost shape

Memory per connection (tens of KB to hundreds). Cost scales with concurrent connections, not message volume. A fan-out broker adds infra.

Alternatives

SSE — Simple one-way push over HTTP, but no client→server channel.
Long polling — Works everywhere but high latency and overhead.

Failure modes

Proxies/load balancers closing idle connections (needs heartbeats).
Sticky-session requirements complicating scaling.
Reconnect storms on network blips without backoff.

Server-Sent Events (SSE), Long polling, Backpressure, Redis, Pub/Sub