OpenAI Software Engineer Interview Experience — System Design for a Real-Time Trivia Battle Royale Platform

Sharing the system design question from one round of my OpenAI technical interview. The question was given on the spot, and the design below is my solution. Happy to discuss.

Question

Design a real-time trivia battle royale platform: dozens to a hundred or so players join a room, questions are released round by round, and each round eliminates the players who answer wrong and the slowest player. The last one alive wins. Spectators can watch a live leaderboard for any room that is in progress.

Requirements breakdown

Functional:

• Matchmaking: group players into a game by skill level
• Real-time sync: the state of every player in the game (alive/eliminated, score) is visible in real time
• Per-round settlement: compute eliminations each round, and rank the players at the end to determine the winner
• Spectating: spectators can watch any room that is in progress

Non-functional:

• Real-time: low latency on every round update
• Scalability: the number of rooms scales horizontally as players grow
• Isolation: a failure in a single room, or spectator traffic, should not affect other rooms

Overall architecture

Client → Matchmaking Service → Match Service (sharded by room_id)
├─ Redis (room state / cache / pub-sub)
└─ Coordination service (shard membership and failover)
Spectating: separate SSE channel

1. Matchmaking Service: waiting queues bucketed by rank. Once enough players have gathered it starts a game, and routes the whole room to one Match Service shard.
2. Match Service (sharded by room_id): the authoritative state machine for a game. An answer first arrives at the shard, is validated, then eliminations are computed per round and broadcast.
3. Redis: high-frequency in-game room state plus pub-sub for the leaderboard; it expires as soon as the room ends.
4. Coordination service (e.g. ZooKeeper / etcd): control plane only, meaning shard registration, heartbeats, and failover. The data plane does not go through it.
5. Spectating channel: a separate long-lived SSE connection, isolated from player traffic, with its own budget.

Key design decisions

• Shard by room_id: all writes for a game land on the same shard, so per-round eliminations need no cross-shard coordination. There is no shared state between shards, so adding shards scales horizontally.
• The shard itself is stateless: in-progress state lives in Redis, and when a shard fails a new shard recovers from Redis, with the coordination service handling the takeover.
• Spectator isolation: SSE fan-out is large, so it gets its own channel and does not eat into the game's latency budget.
• Consistency tradeoff: in-game progress is allowed to be eventually consistent; eliminations and the final ranking follow the single room's authoritative log and are computed correctly once.

Anti-cheat

The server checks that answers are plausible: timestamps are monotonic and the time spent on each question is within a reasonable range. An impossible answer is simply marked as a loss, without interrupting the game.

Takeaways

For this kind of question, I would focus on preparing the basis for sharding and walking through failure recovery. API details were asked about much less.