Design a Live Riddle Showdown With Round Eliminations and Spectators
OpenAISoftware Engineer · Onsite
Last updated
Design the backend for a live multiplayer riddle showdown where wrong or slow answerers are eliminated each round and large audiences spectate in real time. Tests room sharding, authoritative round settlement, mid-round crash recovery, and isolating spectator traffic from gameplay.
You're designing the backend for "Riddle Showdown", a live game show app. Anywhere from a few dozen to a few hundred players join a room together. Every round, a riddle is released to the whole room with a fixed answer window. When the window closes, every player who answered wrong is cut, and among the players who answered correctly, the slowest fraction is also cut. Play continues, round after round, until one player remains or the room runs out of riddles. Anyone — not just players — can open a room that's mid-show and watch a live leaderboard of who's still in and their running score.
Design a system that supports:
- Matchmaking: group waiting players into rooms, roughly balanced by skill, without making anyone wait too long for a room to fill.
- Live round state: every player's alive/eliminated flag and score updates in real time for everyone in the room.
- Authoritative settlement: at the end of each round, the system — not any client — decides who answered correctly and in what order, and applies the elimination rule.
- Spectating: a spectator can join an in-progress room at any time and see a live leaderboard, without being a participant in the round itself.
Non-functional requirements: round outcomes should post within a second or two of the answer window closing, the system should scale horizontally as the number of concurrent rooms grows (design for roughly 2,000 concurrent rooms at up to 300 players each), a crash in one room's backend should not affect any other room, and a room that goes viral with tens of thousands of spectators should not be able to slow down or destabilize the gameplay in that same room.
What to Cover
- How rooms and their state are partitioned across your fleet, and why that unit of partitioning is the right one.
- How you decide, fairly and tamper-resistantly, which answers count as "on time."
- What happens to a room in progress if the process holding its state crashes or is redeployed mid-round — what survives, who takes over, and what players observe.
- How spectator traffic is served so that a popular room's audience size never competes with the resources used to compute eliminations.
Only the rough room size and scale numbers above are given — state any other assumption you need and justify it. The interviewer cares much more about partitioning and failure recovery than about exact API shapes.
Hints
Hint 1
Figure out the smallest group of players a single elimination decision needs visibility into, and make that group your unit of horizontal scaling.
Hint 2
Decide whose clock measures how fast an answer arrived — and what a client could gain by misreporting its own timing.
Hint 3
Walk through a backend process dying right after a riddle goes out but before eliminations are computed. What has to be durable, and who notices the process is gone?
Hint 4
A breakout room can have far more spectators than players. Make sure growing the audience doesn't add load to the path that decides who's eliminated.
Follow-up questions
- How would you shrink the gap between a coordinator crash and a standby reclaiming the room's lease?
- How does a spectator joining mid-round get caught up instantly instead of waiting for the next leaderboard delta?
- Two answers arrive within a few milliseconds of each other at the coordinator — how do you reason about whether that's a fair tiebreak or an artifact of network jitter?
- How would you bootstrap skill buckets for matchmaking for a player who has never played before?
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.