Design a Global Real-Time Chess Service With Matchmaking and Leaderboards

Design the backend for a global, competitive, turn-based board game service in the style of online chess. Players anywhere in the world sign in, ask to be matched against an opponent of similar strength, play a timed game in real time, and watch their rating move on public leaderboards. The service has 10 million daily active users. You are expected to run the session yourself: gather requirements, do the capacity math out loud and use it to justify your storage choices, produce a high-level design, and then improve it. Expect the interviewer to ask where your bottleneck is. ### Constraints and Clarifications - 10 million daily active users, spread across the globe. - Games are two-player and timed. The server, not the client, decides whether a move is legal and how much time each player has left. - Any number you use beyond the daily active users must either be asked for or announced as an assumption. ### Clarifying Questions - How many games does an active user play per day, and which time controls are offered, from very fast to slow? - How long may a player wait in the matchmaking queue, and how close in rating must opponents be? - Is one global leaderboard enough, or are there per-region or per-time-control boards, and how fresh must a player's rank be? - What happens when a player disconnects mid-game: does their clock keep running, and how long do they have to reconnect? - Are spectators, game history and replays, or cheating detection in scope? ### Part 1 — Requirements, estimates and API State the functional and non-functional requirements, then estimate the load: games started per second, moves per second, concurrent games and connections, and storage for finished games. Use those numbers to decide where live game state and finished games live. Define the client-facing API for queueing, playing and reading leaderboards. ```hint Two very different data shapes Compare how often a live game's state changes with how often anyone reads a finished game, and let that difference drive storage. ``` #### What This Part Should Cover - Requirements that separate real-time play from rating and leaderboard work - Back-of-envelope numbers derived from 10 million DAU and stated assumptions - Storage choices justified by those numbers rather than by habit - An API covering the queue, move submission over a persistent connection, and leaderboard reads ### Part 2 — Matchmaking and live play Design matchmaking that pairs players of similar rating quickly, and the live game path that validates moves, runs the clocks, and survives disconnects and game server failures. ```hint Trade wait time for fairness Decide how the acceptable rating gap should change while a player keeps waiting, and what stops one player from being matched twice. ``` #### What This Part Should Cover - Queue partitioning and a rating window that widens over time - Atomic pairing so that no player lands in two games - An authoritative game server with server-side clocks and ordered moves - Reconnects and game server failover without losing or duplicating moves ### Part 3 — Ratings, leaderboards and your bottleneck Show how a finished game updates both players' ratings and the leaderboards. Then identify the weakest component in your own design before the interviewer does, justify the choice with your estimates, and change the design to fix it. ```hint Look for what cannot be split Check each component's peak load against your numbers, and ask which ones hold state that cannot simply be spread across more machines. ``` #### What This Part Should Cover - Exactly-once rating updates for both players when a game ends - A leaderboard structure that answers top-N and any player's rank - A bottleneck named and quantified with the earlier estimates - A concrete redesign of that component and what it costs ### What a Strong Answer Covers - Asks before designing and labels every assumed number - Uses the capacity math to make decisions, not as a ritual - Keeps the game server authoritative over moves and clocks - Handles disconnects, retries and server loss without corrupting games or ratings - Drives the structure and iterates on its own design, including naming its weakest point first ### Follow-up Questions - Two players on different continents are matched. Where does their game run, and how do you keep the clocks fair? - How would you detect and handle a player who uses an engine to choose moves? - A famous player's game attracts a million spectators. What changes? - How would you run a weekly tournament with thousands of simultaneous pairings per round?