Design a Real-Time Online Typing Game With Fair Races and Crash Recovery

Design an online typing game. The report names only the problem; the discussion it describes covered the read and write paths, changes needed at scale, infrastructure edge cases, the trade-offs of a stateful design, latency-critical design, fairness between players, and recovery when a service fails. Assume a competitive game, which the emphasis on fairness implies: players join a race, all type the same passage, see each other's progress live, and are ranked when they finish. Confirm the format, the scale and the rules with the interviewer before designing. ```hint Who owns a live race Decide which component holds a race's state while it is running, and what happens to the race if that component disappears halfway through. ``` ```hint Whose clock decides Think about which timestamps can be trusted when two players on connections with very different latency finish within a few milliseconds of each other. ``` ### Clarifying Questions - Is the game a live race between several players, a solo test against the clock, or both? How many players share one race? - How many concurrent players and races must the system support at peak? - How quickly must one player's progress appear on the other players' screens? - What must be kept after a race: results, speed and accuracy history, leaderboards, replays? - How should cheating be handled, such as scripted typing or a modified client that reports false progress? - What should a player see if their connection drops, or if the server running their race fails? ### What a Strong Answer Covers - Requirements and scale estimates, including the update rate per player and the fan-out of each update to opponents - The race lifecycle (lobby, countdown, running, finished), an API for joining, and a persistent connection for live updates - The live write path for typed input and the read paths for opponents' progress, results and leaderboards - A stateful race server with sticky routing, compared with a stateless design over a shared store - Fairness: a coordinated start, server-side validation of progress and timing, latency differences between players, and cheating - Recovery from dropped connections and failed race servers, durable results, scaling across regions, and monitoring ### Follow-up Questions - A race server crashes in the middle of a race. What do the players see, and what state can be recovered? - Two players finish within a few milliseconds of each other. How do you decide the winner fairly? - How would you detect a bot that types at a perfectly steady, superhuman speed? - A popular race is opened to thousands of spectators. What changes in how updates are fanned out?