Design an Online Multiplayer Chess Service with Real-Time Moves

Design an online chess service: two players on different devices play a game of chess against each other over the internet, each move is checked against the rules of chess and shown to the opponent right away, and the game ends in a win, loss or draw that the service records. This came up as the system design portion of a phone screen for a software engineer role. The prompt was only "chess", so how far the scope extends beyond live two-player games is something to settle with the interviewer. Go past a component diagram. Be ready to explain in detail how a single move travels from one player to the other, who decides whether it is legal and when it happened, and what happens to a game in progress when a server or a connection fails. ```hint Decide who owns the truth of a game Pick one place that holds the authoritative state of each game and accepts or rejects every move, and work out how both players' connections reach that place. ``` ```hint If games are timed, the clock is game state Work out which component decides that a player has run out of time, and what should happen when a move is still in flight as the clock reaches zero. ``` ### Clarifying Questions - Is the scope only live two-player games, or also finding an opponent (matchmaking), ratings, game history and replays? - Are games timed, and if so, which time controls must be supported, from very fast games to games with days per move? - What scale should the design target: concurrent games, active players, and moves per second at peak? - Web, mobile, or both? Must a player be able to reconnect mid-game, possibly from another device? - Are spectators in scope, including a single game watched by a very large audience? - Is cheat detection in scope, or only worth mentioning? ### What a Strong Answer Covers - Functional and non-functional requirements with explicit scale assumptions and a latency target for move delivery - The real-time transport between clients and servers, and how both players of a game reach the same authoritative state - Server-side move validation, turn ordering, and applying each move exactly once despite retries and duplicates - Clock handling that stays fair under network latency, if games are timed - The data model and persistence of games and moves, and recovery of a game in progress after a server fails - Matchmaking and ratings, if in scope, and how a new game is handed to the server that will host it - Scaling: distributing games across servers, routing, and hot spots such as one game with a huge audience - Failure modes and observability: disconnects, reconnects, abandoned games, and the metrics that reveal trouble ### Follow-up Questions - A game server crashes mid-game. How do both players end up back in the same position with correct clocks? - How would you let a very large number of people watch one top game live without slowing it down for the players? - How do you stop a player from submitting two moves for the same turn, or a move after the game has ended? - How would you detect players who use a chess engine during games without adding latency to move delivery?