Design a Live Elimination Puzzle Arena With Spectators
OpenAISoftware Engineer · OnsiteLast updated
Design a real-time game in which up to ~150 players per arena solve timed puzzle rounds, the wrong and slowest are knocked out each round, and large audiences watch live standings. Tests partitioning by arena, authoritative timing, mid-round failover, and isolating spectator fan-out from gameplay.
You are designing PuzzleDrop, a mobile game. Players queue up and are placed in an arena of 50 to 150 people. Each round, every surviving player receives the same short puzzle (for example, a 4-option logic question) with a 12-second window. When the window closes:
- anyone who answered wrong or did not answer is knocked out;
- of those who answered correctly, the slowest 10% are also knocked out (at least one player, unless only one remains).
Rounds repeat until one player remains, or until a round knocks everyone out (then the fastest correct player of the previous round wins). Anyone can open a live arena as a spectator and see who is still alive, round number, and a top-20 leaderboard.
Functional requirements
- Matchmaking that groups players of similar rating into arenas within ~15 seconds.
- Synchronized puzzle release and a server-decided result for each round.
- Live per-player state (alive/out, score, streak) for players in the arena.
- Spectating any in-progress arena, plus a "featured arenas" list.
- Final placements and rating updates written durably after each game.
Non-functional requirements
- Round results delivered to players within 500 ms of the window closing (p99).
- Fair timing: a player 200 ms from the server is not penalized against one 20 ms away; clients cannot fake speed.
- 2M concurrent players at peak (about 20k live arenas) and 10M concurrent spectators, heavily skewed toward a few streamer-hosted arenas.
- A crashed server must not end or corrupt games on other servers; a game whose server crashes mid-round should resume or be voided cleanly.
- Spectator spikes must never slow down gameplay.
Deliver
- High-level architecture and where state lives.
- How arenas are assigned to servers and how a round is settled.
- Your timing and anti-cheat approach.
- Failure handling for a game-server crash mid-round.
- How spectator traffic is served and isolated.
- Rough capacity numbers.
Hints
Hint 1
Every decision in a round only needs that arena's answers. What does that suggest about sharding?
Hint 2
Measure answer time on the server, but think about how to compensate for each player's network delay without trusting the client.
Hint 3
Decide what must be persisted at each round boundary so another server can take over.
Hint 4
Spectators can tolerate a second of delay; players cannot. Give them different paths.
Follow-up questions
- How would you deploy a new game server version without interrupting live arenas?
- A streamer's arena has 3M spectators and they want to send emoji reactions that players see. How do you add that safely?
- How do you detect a player who uses a bot to answer in 50 ms every round?
- How would you change the design if arenas grew to 10,000 players each?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.