Katkat

Design a Live Elimination Puzzle Arena With Spectators

OpenAISoftware Engineer · Onsite

Last 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

  1. Matchmaking that groups players of similar rating into arenas within ~15 seconds.
  2. Synchronized puzzle release and a server-decided result for each round.
  3. Live per-player state (alive/out, score, streak) for players in the arena.
  4. Spectating any in-progress arena, plus a "featured arenas" list.
  5. 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?