Why you cannot horizontally scale a WebSocket server naively
sticky connections problem, load balancer routing, connection-to-process affinity, broadcast across processes, shared state requirement, stateful vs stateless services
The Horizontal Scaling Problem
REST APIs are easy to scale horizontally because each request is independent. WebSocket connections are stateful — a client is pinned to the server process that holds its socket. This creates two problems:
Cross-server broadcast: Client A on Server 1 sends a message. Client B is on Server 2. Server 1 cannot reach Client B directly — it has no reference to that socket.
Reconnection routing: If the client reconnects and the load balancer routes it to a different server, room membership and session state are lost.
Naive round-robin load balancing breaks WebSocket applications at any scale beyond one process. You need either sticky sessions or a shared state layer — typically both.
The Two Solutions
Sticky sessions route each client always to the same server (via IP hash or cookie). This works but creates uneven load and does not solve the broadcast problem. Pub/sub adapter (Redis) solves both: servers publish events to a shared channel and subscribe to deliver them to local sockets. This is the production standard.