What to Expect in the Dream11 System Design Interview

Expect an in person high level design round built from Dream11's own scale problems. Candidates report being asked to design the system that sends lineup notifications about thirty minutes before a match, and other candidates report the Dream11 leaderboard and the Dream11 wallet. The round is held at the Mumbai office, and several candidates describe it as an interactive discussion rather than a test.

You will not receive a generic social network question, but a fantasy sports problem with a traffic spike in it.

The Low Level Design and Machine Coding Question

Reports differ by track, so prepare for both forms of this round. Candidates on the frontend track report a machine coding round, which is a timed session where you write small working code and are graded on whether it runs and how the classes are organized. One reported task was writing a polyfill of Promise.

Backend reports do not describe a separate machine coding round, and instead describe object level design inside the project round, where candidates draw a database schema and explain classes and responsibilities. Prepare both forms, because the difference between them decides how you spend the time. The difference between system design and low level design explains how the two rounds differ.

The Question Types

Real time leaderboards. A leaderboard ranks every team in a contest while a match is in progress. Points change on every ball, contests range from two teams to very large ones, and all of them update together, so the difficulty comes from doing the ranking repeatedly inside a short time budget.

Notification at a spike. The reported lineup notification question gives you two Kafka streams as input, one for users joining a contest and one for lineup data, where Kafka is a system that stores ordered streams of events for other services to read. The system must be elastic, meaning it works for a thousand users and for millions without a redesign.

Wallet and payments. A wallet holds a user balance, and the hard parts of the design are idempotency and correctness, where idempotency means that a retried request does not charge the user twice.

Contest join at peak. Most users join in the minutes before the match starts, so expect questions about queuing, limits per contest, and what the system does when it cannot accept more traffic.

A Walkthrough: Design the Live Leaderboard

1. Requirements, about five minutes. Many contests run at once for the same match, ranks must refresh within about a minute, and two users looking at the same contest must see the same ranks.

2. Ingestion. Read scoring events for the match from a stream, then convert those events into fantasy points using the scoring rules.

3. Computation. Recompute points for each team, group teams by contest, then sort and rank each contest, and because this work is parallel by contest, spread it across a cluster of machines.

4. Storage. Write each result as a new versioned snapshot rather than editing rows, because insert only writes make retries safe and allow a rollback to the previous snapshot.

5. Serving. Cache the popular contests on each web server so reads do not all reach the database, and serve one snapshot version consistently so that a user never sees two partial states.

6. Failure and scale. Say what happens if the computation misses its one minute budget, and degrade to the last good snapshot rather than showing wrong ranks. Explain also how you add machines to the cluster before a large match begins.

What the Interviewer Grades

State requirements and scale before drawing anything, and name your trade-offs aloud, because this round is scored as a discussion. Connect each choice to the user: a wrong rank during a live match is a visible failure. Candidates report follow up questions on databases, so be ready to defend your storage choice with reasons about read and write volume.

Common Mistakes in This Round

• Designing for the average. The average load is irrelevant here, so design for the minutes around match start and say that you are doing so early.
• Skipping consistency. Users compare screens with friends during a match, and if you cannot explain why two devices agree, the design is unfinished.
• Updating rows in place. Editing live ranks creates partial views and makes rollback impossible, while versioned snapshots prevent both problems.
• No answer for overload. Every design needs a plan for the moment when capacity is exhausted, so queues, limits, and graceful degradation belong in your first version.
• Treating payments loosely. A wallet question answered without idempotency and without audit logging fails.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers the queues, caches, and databases that every one of these answers needs, including replication and consistency.
• Prepare the object level design too. Grokking the Object Oriented Design Interview prepares the class design questions that appear in the project round.
• Read the full loop once. The design round is stage three in the Dream11 interview process, and how long it takes to hear back explains what follows it.
• Connect the product to your motivation. The same scale facts support the answer to why Dream11.