Design a Real-Time Multiplayer Typing Race with Typo Freezes and Fair Matchmaking

Design an online typing race game. A race has 2 to 8 players. When a race starts, the game generates a passage of text and every player types it; the first player to type the whole passage wins. If a player types a wrong letter, the game freezes that player for 1 second, during which their input is not accepted. The design must cover the freeze and unfreeze mechanism and how players are matched into races. The follow-ups asked how to rank players by score and how to reduce the effect of different players' network delays so that the game stays fair. ### Constraints and Clarifications - A race has between 2 and 8 players. - A wrong letter freezes the player for exactly 1 second. - The winner is the first player to finish typing the passage. - Scale, regions, passage length and the scoring formula are not given. Ask, or state your assumptions. ### Clarifying Questions - After a wrong letter, does the cursor stay on the missed letter, so the player must type it correctly after the freeze, or does the game move on? - Are players matched only with strangers, or can friends race in private rooms? How long may a player wait for a match, and can a race start with fewer than 8 players? - What does "score" mean: a per-race result (speed, accuracy, finishing place), a persistent rating, or both? Is the ranking global, regional or among friends? - How many concurrent players and races should the system support, and in which regions? - What happens when a player disconnects in the middle of a race? ### Part 1 — Race session and the freeze mechanism Design what happens from the moment a race starts until a winner is declared: how keystrokes travel, where they are validated, how each player sees the others' progress, and how a 1-second freeze is applied and lifted. ```hint Decide who is the referee The client has to react to typing instantly, but a client can lie. Decide whose view of the race counts and what the other side does with its copy. ``` ```hint What does "frozen" need? Think about the smallest piece of state that answers "is this player frozen right now?" and whether anything actually has to happen at the moment the freeze ends. ``` #### What This Part Should Cover - Connection model, and the race state kept per room and per player - Keystroke validation, the freeze and unfreeze logic, and what happens to keys typed while frozen - Sending progress to the other players efficiently, and declaring the winner - Disconnects and game server crashes during a race ### Part 2 — Matching players into races How are 2 to 8 players grouped into a race, and how does the race start for all of them? ```hint Full rooms versus short waits Waiting for 8 players gives better races; starting quickly keeps players happy. Look for a rule that trades the two off as a player's wait grows. ``` #### What This Part Should Cover - The matchmaking queue, the room-formation rule and its timeouts - Preventing one player from being placed in two races when several matchmakers run - Handing the room to a game server and getting every client connected before the start ### Part 3 — Ranking players by score Players should be ranked by score. Define the score, and design how rankings are computed, stored and queried. ```hint Two different rankings A ranking inside one race and a ranking across all players differ enormously in size and in how often they change. ``` #### What This Part Should Cover - A per-race result and a long-term rating, and when each one updates - Storage and query paths for the top of the ranking and for one player's own rank - How the rating feeds back into matchmaking ### Part 4 — Fairness under different network delays Players connect with different network delays. How do you reduce the effect of delay so that the fastest typist wins, rather than the player closest to the server? ```hint Arrival order is not typing order A message from a distant player arrives later even if it was typed earlier. Think about which clock the result should be measured on, and how the server can trust it. ``` #### What This Part Should Cover - A synchronized start despite different delays - Measuring finish times and freezes independently of delay, and validating any time a client reports - Server placement and latency-aware matching ### What a Strong Answer Covers - Clarifies the freeze semantics, the match timing and the meaning of score before designing - A server-authoritative race with client-side prediction for responsiveness - A freeze implemented without per-player timers and enforced consistently on client and server - Concrete numbers for message rates and for how rooms map onto game servers - Fairness and anti-cheat treated together, since trusting client timestamps creates a way to cheat ### Follow-up Questions - A player's script types at a perfectly steady 300 words per minute. How do you detect and handle it? - The game server hosting a room crashes 20 seconds into a race. What do the players see, and what happens to results and ratings? - How would you add a spectator mode for a race watched by thousands of viewers? - After correcting for delay, two players' finish times differ by 5 ms. Do you declare a tie? How confident can you be in that order?