Design a Real-Time Multiplayer Typing Race with Matchmaking and Spectators

Design a real-time multiplayer typing race platform. A user chooses a language and is matched into a race of 2 to 8 players, and everyone in the race types exactly the same text. While the race runs, each participant sees the other racers' progress and typing errors in real time. Every typing error freezes that racer's input for 1 second. Spectators can watch races as they happen. ```hint Who decides what counts Each error costs a 1-second freeze. Decide which component knows the text, judges every keystroke and enforces the freeze, and what a racer on a slow or jittery connection experiences when that component is far away. ``` ```hint Racers and spectators are different audiences A race has at most 8 players but could have many viewers. Decide how often each audience needs updates and whether the same machines should serve both. ``` ```hint When is a race full enough? Races can run with as few as 2 players. Decide when a waiting group should stop waiting for more players, and how to avoid placing one player in two races. ``` ### Constraints and Clarifications - A race has 2 to 8 players, matched by the chosen language, all typing identical text. - Each typing error freezes that racer's input for 1 second. - Racers see each other's progress and errors in real time; spectators can watch races. - Not given: the number of users or concurrent races, the latency target for the live view, how long matchmaking may wait, how a race is won and ended, whether players are matched by skill, and anti-cheating requirements. Ask, or state your assumptions. ### Clarifying Questions - Does "language" mean the natural language of the passage, a programming language for code passages, or both? Does it change the character set the client must handle? - How long may a player wait in matchmaking, and may a race start with fewer than 8 players when the wait runs out? - After an error, is the wrong key simply rejected so the racer types the correct character once the freeze ends, or must the racer delete it? Are keys pressed during the freeze discarded? - How is a race decided and ended: ranking by finish time, a time limit for the slowest racers, partial credit for progress? - How many concurrent racers and spectators must the system support, and how live must "real time" feel for each group? - Do results feed a ranking, and must the system resist cheating such as scripted typing or pasted text? ### What a Strong Answer Covers - Settles language semantics, the race start rule, error and freeze semantics, and scale before designing - A matchmaking design that groups players per language into races of 2 to 8, with a clear start rule and no double placement - A server-authoritative race loop that validates keystrokes against the text, enforces the 1-second freeze, and broadcasts progress and errors at a stated rate over a stated transport - A spectator path that scales independently of the racers and cannot slow a race down - Fairness under network latency (synchronized start, freeze timing, finish order) and handling of disconnects and race-server failure - A data model, APIs and estimates sized to the stated assumptions ### Follow-up Questions - A racer's connection is slow and jittery. How do you keep the freeze and the finish order fair to them and to everyone else? - One race is featured on the home page and draws a very large audience. What changes in the spectator path? - The server hosting a live race crashes halfway through. What do the racers see, and what can you recover? - A racer finishes impossibly fast. How do you detect scripted typing, and what data must you keep to do it?