Design a Real-Time Trivia Battle Royale Platform with Live Spectating

Design a real-time trivia battle royale platform. Dozens to a hundred or more players join a room. Questions are released round by round, and at the end of each round the players who answered incorrectly and the slowest players are eliminated. The last player standing wins. Spectators can watch the live leaderboard of any room that is in progress. The platform needs: - **Matchmaking**: group waiting players into rooms by skill level. - **Real-time state**: each player's state in a room (alive or eliminated, score) is visible in real time. - **Round settlement**: eliminations are computed at the end of every round, and the final ranking and the winner at the end of the game. - **Spectating**: spectators can open any in-progress room and follow its leaderboard. Non-functional goals: low latency for each round's updates, horizontal scaling as the number of rooms grows with the number of players, and isolation, so that a failure in one room or heavy spectator traffic does not affect other rooms. ```hint What one decision depends on Ask which players' answers a single elimination decision needs, and let that drive how you split rooms across servers. ``` ```hint Whose clock measures speed Players sit at different network distances from your servers. Decide whose clock measures answer speed, and what a client could gain by lying about it. ``` ```hint Crash in the middle of a round Walk through a game server dying after a question was released but before the round was settled. Decide what must survive, who takes over, and what the players see. ``` ```hint Viewers are not players A popular room may have far more viewers than players. Keep that traffic from competing with the game itself. ``` ### Constraints and Clarifications - Only the room size is given. State how many concurrent rooms, players and spectators you design for. - Expect the discussion to focus on how work is partitioned across servers and on recovering from a server failure in the middle of a game; API details matter less. ### Clarifying Questions - How many of the slowest players are eliminated each round: a fixed number, a fraction of the survivors, or everyone past a time cutoff? What happens if every remaining player answers incorrectly? - How long is each round's answer window, and is there a maximum number of rounds? - Is answer speed measured from when the server releases a question, or from when each player receives it? - How many concurrent rooms, players and spectators should the design handle at peak? - How fresh must the spectator leaderboard be: as fast as the players' view, or can it lag slightly? - Can a player who disconnects rejoin a game in progress? ### What a Strong Answer Covers - Components for matchmaking, game execution, real-time delivery to players and spectators, and room-state storage - A justified partitioning key, and how rooms are placed on servers and moved between them - An authoritative round settlement that eliminates players exactly once, with fair speed measurement and a defined tie rule - Recovery from a game server failure mid-round: what state is durable, how failure is detected, who takes over, and how two servers are prevented from running the same room - Isolation of spectator fan-out from player traffic, and of rooms from one another - Server-side validation of answers against cheating, without stalling the round ### Follow-up Questions - The coordination service declares a game server dead, but the server was only paused and resumes sending results. How do you stop it from corrupting its former rooms? - One room suddenly attracts a million spectators. What changes on the spectator path? - Redis loses the last second of writes during its own failover. Which room data can you afford to lose, and which must be durable elsewhere? - How would you keep matchmaking fair when few players of a given skill level are waiting?