Dream11 system design: handling toss rush edits

The interview question goes like this. Two minutes before the toss, millions of users are swapping captains, and the app has to keep up. How do you handle it?

This is a standard interview design, not Dream11's own system. The reel gives the short version. Here's the same idea with more room.

Why writing straight to the database fails

The first answer most people give is simple. App calls API, API writes to the database. Every edit goes straight in.

It works until the toss. Everyone edits at the same moment, and the database chokes. So the design needs a buffer between "the user pressed save" and "the database has the team".

The reel boils the requirements down to three. An edit is accepted immediately. Edits are written in order. The contest locks at the deadline. Think of the two-minute rush as Tatkal at ten o'clock.

What OK actually means

The phone sends a small edit, say a captain swap. The API checks login and checks the deadline, then replies OK.

That OK means the edit was received. It does not mean it was saved. Keeping those two apart is what lets the API answer fast without waiting on the database.

After that, the edit goes into an edit queue. It's an ordered line, like a counter for the Mumbai local, and it holds the rush. The database gets edits in order.

Worker, deadline and the last edit

A worker pulls edits off the queue and writes them to the team database.

The deadline is judged by the API's timestamp, not by when the worker gets around to the edit. So if an edit arrives late, the API rejects it. A slow queue never turns a late edit into a valid one.

There's also a shortcut. If one team gets five edits, only the last one matters. The older four are useless, because the last edit is the team. So write only that one.

When the queue gets long

The queue is the weak spot. In a rush it grows, and if workers only scale up after the spike, they start late. Edits sit and wait. On the reel's chart, the gap between edits and worker capacity is the overload.

The fix is to add workers before the toss, not after. The queue stays short and edits get saved on time.

The full flow, end to end: accept the edit, order it in the queue, save it with a worker, lock at the deadline.

Next time someone says "just add more servers", ask where the edits wait and who judges the deadline. Sketch the flow yourself: phone, API, queue, worker, team database. Then say out loud what OK means at each step.