Scaling WebSockets

WebSocket scale challenges differ from HTTP:

Long-lived connections: each user uses one TCP connection for hours/days. A 100k-user app needs ~100k open connections at once. Plan ulimit, file descriptors, kernel buffers.

State: HTTP is stateless; WS is stateful. Each connection has user identity, subscriptions, pending messages. Sticky sessions (route same user to same server) simplify state.

Pub/Sub backplane: when "user A" needs to receive a message but is connected to "server 5", how does server 5 know? Solutions:

• Redis Pub/Sub: publish to channels; all servers subscribed receive.
• Kafka: durable, high-throughput.
• NATS: lightweight pub/sub for microservices.

Architecture:

                            +------------+
                          +-+ Redis Pub  +-+
                          | +------------+ |
                          v                v
[client]--ws-->[server1]                 [server2]<--ws--[client]
              (sub: user1)               (sub: user2)

When server1 wants to send to user2: PUBLISH on Redis; server2 (subscribed to user2's channel) receives and forwards.

Horizontal autoscale: with sticky sessions, scale-up creates HOT servers (existing connections don't migrate). Scale-down requires gracefully draining: stop accepting new, ask clients to reconnect to others.

For massive scale: Cloudflare Workers, Cloudflare Durable Objects, AWS API Gateway WebSocket support. Offload the connection-per-server problem to managed infra.