Scaling WebSockets Across Nodes with Redis Pub/Sub

Scaling WebSocket connections across multiple server nodes requires solving the statefulness problem: WebSocket connections are pinned to one JVM, and an in-memory broker has no knowledge of sessions on other instances. A broadcast message sent on instance A never reaches clients connected to instance B without a shared backbone.

Two main approaches:

• Custom Redis pub/sub: each server instance subscribes to channels mapped to STOMP destinations; when any instance receives a client message, it publishes to Redis, which fans out to all instances, each forwarding to its local sessions; the downside is that Redis pub/sub has no persistence — if an instance is disconnected when a message arrives, it's gone permanently
• STOMP broker relay with RabbitMQ: each server instance maintains relay connections to the same broker cluster; the broker handles subscription tracking, cross-node routing, and user-specific destinations — things you would have to build yourself with Redis; this is the cleaner path for most production systems

The sticky session requirement:

• Either approach requires sticky sessions at the load balancer so the HTTP upgrade and subsequent frames hit the same instance; without this, the STOMP CONNECT frame lands on one instance while subsequent frames may land on different instances
• nginx's proxy_read_timeout defaults to 60 seconds — this silently kills idle WebSocket connections; set it to 3600s and let STOMP heartbeats handle dead connection detection

Connection draining:

• Rolling deployments without draining cause all clients on the shutting-down instance to reconnect simultaneously — a thundering herd that can overwhelm the remaining instances

I recommend the STOMP broker relay with RabbitMQ over custom Redis pub/sub — the broker handles user destination routing across nodes automatically, which is the hardest part to implement correctly yourself.