How the interviewer opens it
“Design infrastructure that keeps millions of WebSocket connections open and delivers real-time events to clients. Support clients that disconnect or receive data slowly.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Connections and sessions
- Traffic and read:write mix
- Event size
- Latency
- Delivery and order
- Durability and availability
- Reconnects and reset
- Connection churn
- Slow clients
- System boundaries
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Maintain authenticated WebSocket connections across many servers.
- Route each user's events to every active session.
- Resume event delivery after a reconnect within a fixed retention window.
- Bound resource use during slow clients, connection bursts, and server failures.
Usually out of scope
- Application business rules
- Room broadcasts
- Cross-region delivery
- Identity service implementation
- Snapshot API implementation, but not its cursor contract
What interviewers ask about
- Connection owners
- Several sessions can share one user. A reconnect changes one session's owner while old routes and disconnect notices remain.
- Events after a reconnect
- Socket writes do not prove application receipt. Replay, live events, and snapshot state must agree on the same event boundary.
- Slow clients
- A small slow-client population can consume gateway memory and delay healthy clients. No finite queue fixes a sustained rate mismatch.
- Fleet failures
- Persistent sockets require spare capacity before a failure. Reconnect bursts also stress TLS, authentication, and the connection directory.
Common mistakes
- The design expects the load balancer to find a user's existing socket.
- The directory stores one connection per user and loses other sessions.
- The design treats a successful socket write as proof of application receipt.
- The reconnect flow leaves a gap between replay and live delivery.
- The reset flow uses a snapshot without its exact cursor or resumes from the expired cursor.
- The design gives slow clients unlimited queues and depends on new servers during a reconnect burst.
The bar by level
- Senior (L5/E5)
- The candidate resolves owner races with connection identities and generations. The design coordinates ordered replay with live events. The reset protocol uses a consistent snapshot cursor. The candidate quantifies reconnect load and defines queue limits.
- Staff (L6+/E6+)
- The candidate proves that reset cannot skip concurrent events or reuse an expired cursor. The design contains overload across routers, gateways, and shared services. The candidate budgets failure capacity, recovery traffic, and directory costs. The candidate defines safe fleet replacement and availability trade-offs.