Question presented to candidate: "We have a chat and live-update product that is about to hit a million concurrent WebSocket connections. One server cannot hold them all, and a message sent by a user on one server has to reach recipients on other servers. Walk me through how you would build this with Redis Pub/Sub, with numbers, and tell me what breaks first."
What a strong answer should cover:
- A gateway tier that only holds sockets, sized with a worked estimate (connections per node, memory per connection, headroom for a lost node), plus OS limits: file descriptors and the ephemeral port range between a proxy and a backend
- Cross-node fan-out with Redis Pub/Sub: gateways subscribe only to channels for rooms their sockets are in, and the publish path is persist first, then publish
- Channel design trade-offs (one global channel vs per-room vs per-gateway) and when each wastes work; sharded Pub/Sub (Redis 7.0,
SPUBLISH/SSUBSCRIBE) so cluster traffic stays within one shard - Redis Pub/Sub is at-most-once and keeps nothing: pair it with a durable log and client resume by sequence number
- Slow consumers and backpressure: the
client-output-buffer-limit pubsubcutoff, per-socket send queues, and what happens at 10x (hot rooms, reconnect storms)
Clarifying questions expected:
- What is the room size distribution (mostly 1:1 and small groups, or a few huge broadcast rooms)?
- Message rate and size at peak, and is delivery allowed to be lossy (typing indicators) or must it be reliable (messages)?
- Is there an existing durable store for messages, and how long must a disconnected client be able to resume?
Code / implementation expected: Optional โ a design with numbers; the example simulates the fan-out counts, the cluster hash slot and a slow-subscriber cutoff in four languages.