Why it matters

Growing WebSocket load exposes architectural weaknesses. Getting the scaling story right from the start avoids painful rewrites.

Advertisement

The architecture

Sticky sessions: LB routes each client to same backend for connection lifetime. Cookie-based, IP hash, or header-based.

Pub/sub: Redis Pub/Sub, Kafka, or NATS to broadcast messages across WebSocket server nodes.

WebSocket scale stackSticky LBone WS per nodePub/sub backbonecross-node fanoutGraceful shutdowndrain connectionsRedis Pub/Sub common for small; Kafka or NATS for very high fan-out
Scaling components.
Advertisement

How it works end to end

Message flow: user A → WS node 1. Node 1 publishes to pub/sub topic. All WS nodes subscribe. Each forwards to its connected users for that topic.

Shutdown: send close frames to connected clients, wait for reconnect elsewhere. Kubernetes-friendly.

Backpressure: slow clients delay whole server if not handled. Bound outbound queue per connection.