# Design an Online Chess Service from Launch to Scale Design an online chess service. Players enter matchmaking, are paired into games, exchange legal moves in real time, and receive a final result. The initial product has uncertain traffic, so begin with the simplest dependable design and show how it evolves as load and availability requirements become clear. Deepen the discussion around matchmaking, authoritative game state, connection routing, and move timeouts. ### Constraints & Assumptions - The server is authoritative for move order, legality, clocks, and game outcome. - Clients can disconnect, reconnect, retry, or send duplicate and stale moves. - Each game has a time-control policy, and server-side deadlines decide timeout losses. - Matchmaking should avoid assigning one player to two simultaneous games. - Scale is unknown at launch; avoid components that are not yet justified. ### Clarifying Questions to Ask - Are games casual, rated, or both, and how does that affect matchmaking? - Which time controls and reconnect grace periods are required? - Must spectators, chat, or game-history analysis be supported? - What latency and regional-availability targets matter? ### Part 1: Initial Architecture and State Model Define the APIs, game state machine, persistence, and real-time connection flow for a modest launch. #### What This Part Should Cover - Durable game identity, participants, move sequence, clocks, status, and result. - Optimistic version or expected-ply checks for move idempotency and ordering. - A simple matchmaking queue and one authoritative owner per active game. ### Part 2: Routing, Timeouts, and Failure Recovery Explain how clients find the current game owner, how moves and updates are routed, and what happens when a process or connection fails. #### What This Part Should Cover - Directory/routing metadata with fencing against two active owners. - Server-calculated deadlines using persisted clock state, not trusted client timers. - Reconnect snapshots, event replay, duplicate suppression, and failover. ### Part 3: Scaling and Operations Show how the design changes at increasing user counts and what evidence triggers each change. #### What This Part Should Cover - Partitioning active games by game ID and matchmaking by region/rating/time control. - Hot-queue fairness, backpressure, and regional trade-offs. - Metrics, load tests, game-invariant checks, and staged migration from the simple design. ### What a Strong Answer Covers - An authoritative, versioned game state and deterministic move processing. - Safe single-game ownership, reconnect behavior, and timeout semantics. - Matchmaking correctness and fairness, not only queue data structures. - Evolution driven by measured traffic, availability, and latency rather than speculative complexity. ### Follow-up Questions - How would you prevent a failover from declaring an incorrect timeout? - How would rating updates remain idempotent when game-completion events are retried? - How would you add spectators without increasing latency on the move path?