Design a Real-Time Multiplayer Typing Race Game

Design an online multiplayer typing game. The interviewer compared it to designing online chess: players are matched into a game, the game's state has to stay in sync between them in real time, and the game produces a result. The report gives only this prompt, so settle the scope first. In its usual form, two or more players race to type the same passage, each player sees every opponent's progress live, and the game ends with a ranking by finishing time. ```hint Who decides the result The clients do the typing, but a client can lie. Decide which component is the authority for each player's progress and finishing time, and what it checks before accepting a report. ``` ```hint Faster than chess A chess player moves every few seconds; a typist presses several keys per second, and every opponent wants to see it. Work out what that does to the message rate of one game, and what you can send less often without the race looking wrong. ``` ### Constraints and Clarifications - Not given: players per game, how players are matched, what ends a game, whether results are ranked, and the expected number of concurrent players. Ask, or state your assumptions. ### Clarifying Questions - How many players are in one game, and can someone join a game that has already started? - How are players matched: a public queue, private rooms joined with a code, or matching by skill rating as in online chess? - What ends a game: everyone finishing, a time limit, or a fixed number of finishers? - What does a player see of opponents: a progress bar, live words per minute, or every keystroke? - Do results change a rating or a leaderboard, and how much effort should go into stopping scripts and pasted text? - What happens when a player disconnects partway through a race? - How many players are online at peak, and from which regions? ### What a Strong Answer Covers - Settles game size, matching, end conditions, what opponents see, and ranked versus casual play before designing - A game lifecycle (lobby, countdown, race, finished) with a single owner of each live game's state - A real-time channel such as WebSockets, routing of every player of a game to the server that owns it, and a bounded rate of progress updates - Server-side validation of progress and finishing times, a synchronized start, and anti-cheat for ranked games - Matchmaking, and durable results, ratings and leaderboards kept off the real-time path - Disconnects, reconnects, server crashes mid-game, scaling, and monitoring ### Follow-up Questions - A player's connection drops for five seconds in the middle of a race. What do they and their opponents see, and how does the player resume? - The server that owns a live game crashes. What is lost, and what happens to ratings? - How would you detect a player who uses a script to type the passage? - A popular race has thousands of spectators. How do you deliver live progress to them without overloading the game server?