System Design Interview
Live quiz platform inspired by Kahoot: games routed by PIN to WebSocket gateways, one owner per game state machine, questions broadcast to all players at once, server-timestamped answers, and live leaderboards in Redis sorted sets. A teaching design.
See why polling and scoring in the database can't run thousands of games at once.
What was missing: Nothing yet.
Why that's risky: Polling floods the server with empty requests, players see each question at different moments (up to the polling interval apart), and every answer is a database write.
What gets added: One server where players poll every second for the next question and submit answers that are scored straight into the database.
Trade-offs: Simple request/response, but unfair and wasteful.
Keep players connected and give every game a single source of truth for its state.
What was missing: Players polled, and game state lived only in database rows.
Why that's risky: Each player still has to ask for the next question; there's no single 'go' that reaches everyone together.
What gets added: WebSocket gateways behind a router that groups players by game PIN, a quiz service and database for creating quizzes, a game service that runs each game's state machine on one owner server, and an answer service that timestamps answers with server time.
Trade-offs: One owner per game is simple and consistent; a game is limited to what one server can coordinate (tens of thousands of players).
Start every question for every player at the same moment.
What was missing: Questions reached players whenever they next asked.
Why that's risky: Scoring every answer with a database write is the bottleneck when 50,000 players answer within the same few seconds.
What gets added: A per-game channel: the game service publishes each question once, and the push side of every gateway holding players of that game sends it to all of them together.
Trade-offs: Publishing once per game keeps the game service independent of how many players there are.
Absorb answer bursts and show standings instantly after each question.
What was missing: Every answer was scored with a database write, and standings needed a sort over all scores.
Why that's risky: Question media is still served by our servers, bots can flood games, and nobody sees delivery skew.
What gets added: An answer stream, scorers that award points for correctness and speed into a Redis sorted set per game, a leaderboard service reading ranks from it, and a results writer saving answers and scores to the results database in batches.
Trade-offs: Standings appear a moment after a question closes, once scoring has caught up.
Serve question media from the edge, block bots and watch fairness.
What was missing: Question images came from our servers, nothing stopped bots, and fairness wasn't measured.
Why that's risky: Remaining risk is regional: players far from the game's region see more latency.
What gets added: A media CDN for question images and videos, an answer limiter (one answer per player per question, join caps per IP), and monitoring of question delivery skew, answer latency, late answers and leaderboard lag.
Trade-offs: Media is preloaded before each question starts so it doesn't delay the reveal.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
