Katkat
Back

Design a Live Trivia Buzzer Arena with Wrong-Answer Lockouts

OpenAISoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

Design an online trivia game where 2 to 8 players race to buzz in and answer each question correctly, and a wrong answer locks that player out for one second. Tests authoritative server design for real-time input, lockout state, matchmaking, and fairness across differing network latencies.

Design a live trivia buzzer game. A match has 2 to 8 players. Each round, a question appears to every player at once; players race to buzz in. The first player whose buzz the server accepts gets to answer. A wrong answer locks that player's buzzer for 1 second and reopens it for everyone else; a right answer scores the round and starts the next question.

Cover the buzz-in/lockout mechanism and matchmaking. Follow-ups cover ranking players by score and reducing the effect of differing network latency, so the game stays fair regardless of connection quality.

Constraints and Clarifications

  • A match has 2 to 8 players; a wrong answer locks that player out for exactly 1 second.
  • Whoever the server accepts as "first to buzz" gets the exclusive chance to answer that round.
  • Scale, regions, question bank size, and the scoring formula aren't given — state your assumptions.

Clarifying Questions

  • Once a lockout ends, can that player buzz again on the same question, or does the question move on regardless?
  • Are players matched only with strangers, or can friends play in a private room, and how long does a player wait before a match starts short of 8?
  • Is "score" a per-match result, a persistent rating, or both?
  • How many concurrent matches/players should this support, across how many regions, and what happens if a player disconnects mid-match?

Part 1 — Match session and the buzz/lockout mechanism

Design what happens from a question appearing to a winner being decided: how buzz-in signals travel, where "who was first" is decided, how every player sees buzzer state (open, locked to one player, or someone's lockout ticking down), and how the lockout is applied and lifted.

A client has to feel instant, but a client's claim of "I buzzed first" can't be trusted alone. Decide whose clock is authoritative, and what every other client's buzzer display is relative to that.

Think about the smallest fact that answers "is this player locked out right now," and whether anything must actively fire the instant a lockout ends, or whether checking a stored expiry on the next attempt is enough.

What This Part Should Cover

  • Connection model and what state lives per match versus per player
  • The buzz-in flow: client sends an attempt, server resolves order, server broadcasts the result
  • How a lockout is represented and applied, and reflected to the locked player versus everyone else
  • What happens when two buzz-ins are genuinely very close in time

Part 2 — Matchmaking

Design how strangers (or friends, in a private room) get placed into a match, how long a player waits before starting short of 8, and how private rooms differ from public matchmaking.

Follow-ups to address

  • How would you compute and update a persistent player rating across matches?
  • How do you prevent a low-latency player from having a structural buzz-in advantage over an equally fast but higher-latency one?

Hints

Hint 1

Make the server the single source of truth for buzz order: clients send a buzz attempt as soon as the player taps, and the server is the only one who decides who 'got there first,' based on when each message is received (adjusted for measured latency, see the fairness follow-up).

Hint 2

Lockout can be represented as a single 'locked_until' timestamp per player, checked when their next buzz attempt arrives — you don't need a timer firing an event at exactly the 1-second mark.

Hint 3

For matchmaking, separate 'find me any open match' (a queue plus a short countdown timer that starts the match early if 8 fill up, or at a deadline with fewer) from 'create a private room with a join code' (no matchmaking queue at all, just membership).

Hint 4

For latency fairness, consider having each client report an estimated round-trip time during connection setup, and having the server adjust each player's buzz timestamp by their estimated one-way latency before comparing arrival order.

Follow-up questions

  • How would you detect and handle a player who disconnects mid-match — pause the match, substitute a bot, or let the match continue without them?
  • How would you prevent a modified client from sending buzz attempts that claim an artificially early timestamp?
  • How would this design change if questions needed to support partial credit or multiple correct answers instead of one right answer per round?
  • How would you shard matches across multiple servers while keeping a single global matchmaking queue?