Dream11 Fantasy Sports.

How Do You Let Fifteen Million People Change Their Minds in the Same Thirty Minutes?

It is a Sunday evening in April 2025 in Chennai. Karthik Rao has been building teams for tonight's match at Chepauk since lunch: three of them, each eleven players inside a budget of 100 credits, each with a captain who scores double and a vice-captain who scores one and a half times. At 7:00 pm the coins go up. At 7:01 the playing elevens are announced, and the bowler Karthik made captain in two of his teams isn't in his side's eleven.

He has until 7:30, the scheduled start, to fix it. So does everyone else. Millions of phones open the app in the same minute to read the same two team sheets, re-pick their captains and join contests they were waiting to join until the lineups were known. At 7:29:58 Karthik saves his last edit and joins the biggest contest of the night, one entry among millions. At 7:30:00 every team in the match must freeze, exactly, everywhere. Then, for three and a half hours, every ball bowled changes the points of a few players, and with them the score and rank of tens of millions of teams.

This is the system we'll design today.

The Interview Begins#

You're interviewing at a sports-tech company. The interviewer shares two screenshots from the same phone: a team-edit screen at 7:29 pm with "Deadline in 00:01:12" in red, and a leaderboard at 9:40 pm reading "Rank 1,84,210 of 79,00,000 · 412.5 pts".

Your Questions#

Functional Requirements#

Non-Functional Requirements#

The Toss-to-Deadline Window#

Live Points and Ranks#

Money#

Key Metrics Summary#

System Architecture#

%% title: A fantasy platform: writes until the lock, ranks after it
flowchart TD
  subgraph L1["Layer 1 · Users and data"]
    direction LR
    APP@{ icon: "sd:phone", label: "Fantasy app<br/>teams, contests, ranks" }
    FEED@{ icon: "sd:stream", label: "Score feed<br/>ball by ball" }
  end
  subgraph L2["Layer 2 · Edge"]
    direction LR
    CDN@{ icon: "sd:cdn", label: "CDN<br/>lineups, contest lists" }
    GW@{ icon: "sd:gateway", label: "API gateway<br/>priority, shedding" }
  end
  subgraph L3["Layer 3 · Before the deadline"]
    direction LR
    TEAM["Team service<br/>validate, version"]:::service
    CON["Contest service<br/>spot counters, templates"]:::hot
    LOCK["Lock service<br/>match OPEN to LOCKED"]:::core
    WAL["Wallet and ledger<br/>debit, credit, tax"]:::core
  end
  subgraph L4["Layer 4 · After the deadline"]
    direction LR
    PTS["Points engine<br/>players, lineups"]:::core
    RANK@{ icon: "tech:spark", label: "Rank engine · Spark<br/>histograms, top lists" }
    LB@{ icon: "tech:redis", label: "Redis<br/>ranks per ball" }
  end
  subgraph L5["Layer 5 · State"]
    direction LR
    KV@{ icon: "sd:database", label: "Team and contest store<br/>strongly consistent" }
    BUS@{ icon: "tech:kafka", label: "Kafka<br/>joins, balls, points" }
  end
  APP ==> CDN
  APP ==> GW
  GW ==> TEAM
  GW ==> CON
  CON --> WAL
  TEAM --> KV
  CON --> KV
  LOCK -.->|"lock at start"| KV
  FEED ==> PTS
  KV -->|"frozen lineups"| PTS
  PTS ==> BUS ==> RANK ==> LB
  GW --> LB
  class APP client
  class FEED external
  class CDN,GW edge
  class RANK service
  class LB cache
  class KV store
  class BUS queue

KEY INSIGHTS:

• The deadline divides the system. Before it, the hard problem is concurrent writes in a spike; after it, the data is frozen and the hard problem is recomputation and fan-out
• Reads never touch the write path. Lineups, contest lists and rules come from the CDN and caches; ranks come from per-ball summaries, never from a query over entries
• One lock, checked everywhere. Every team write and every join reads the match state in the same atomic operation that performs the write

Data Flow: Karthik's Last-Second Edit and Join#

%% title: Karthik edits his captain and joins the mega contest at 7:29
sequenceDiagram
  autonumber
  participant A as Karthik's app
  participant G as API gateway
  participant T as Team service
  participant C as Contest service
  participant W as Wallet
  participant S as Store
  A->>G: Save team 2, new captain, edit id e81
  G->>T: Tier 1 request, admitted
  T->>S: Write version 5 if match OPEN
  S-->>T: Written at 7:29:58
  A->>G: Join mega contest with team 2, join id j44
  G->>C: Tier 1 request, admitted
  C->>C: Take a spot from shard 17
  C->>W: Debit entry fee, key j44
  W-->>C: Debited
  C->>S: Entry recorded if match OPEN
  S-->>A: Joined, spot held

MEANWHILE, IN PARALLEL:

• At 7:30:00 the lock service flips the match to LOCKED; any write that reaches the store after that fails its check and the app shows "deadline passed"
• A snapshot job then freezes every team into a table of distinct lineups for the points engine

Deep Dive 1: The Toss-to-Deadline Spike (Week 10 Concepts: Capacity Planning; Week 4: Thundering Herd)#

This builds on Week 10, Day 4 · Capacity Planning, Week 4, Day 3 · Thundering Herd and Week 3, Day 3 · Backpressure and Flow Control.

What is published: Dream11 wrote in 2021 that its traffic is "very spiky", that it runs more than 100 microservices and over 30,000 compute resources for peak IPL traffic, and that a data-science model (XGBoost over "over 200 variables") forecasts hourly concurrency by match tier. Its in-house platform, Scaler, provisions ahead of time: an AWS case study (2023) describes forecasts 5 days before a match, an updated forecast 2 hours before, and scaling that now starts 1 hour before (it used to take 3), across 700+ auto-scaling groups and 200 load balancers, with scaling time cut "from multiple hours down to about five minutes". In one case the updated forecast was "almost double what was projected earlier", about 10 million users. Dream11 also load-tests every service with its own tools (Torque, Playground) in "Game Days", and its contest service keeps 10 copies of the hottest cache keys so no single node serves them all.

• Forecast, then pre-scale in slabs. Each match gets a tier and a predicted peak; capacity is set per tier for before, during and after the match, scaled up an hour ahead and down after. Autoscaling remains as a safety net, not the plan.
• Stateful systems scale earlier. App servers boot in minutes; adding nodes to a database or cache cluster means rebalancing data, which must finish well before the toss.
• Edge traffic is the biggest. The AWS write-up notes about 245 million requests a minute at edge services against about 69 million at a non-edge service: most requests should end at the CDN or the gateway's caches.
• Make the herd small. Lineups, contest lists and player stats are versioned and pushed; clients add jitter to polling; a notification goes out in waves. The patterns are the ones in the Week 4 thundering herd lesson: request coalescing, early refresh and stale-while-revalidate.
• Admission by tier. The gateway tags each route with a tier and watches tier-1 latency; when it climbs, it rejects tier-3 requests with a "retry later" before they reach a service, then serves tier 2 from stale caches. A user who can't load someone else's profile is fine; a user whose team didn't save is not.

# gateway/shedding.py

"""
Priority load shedding at the gateway (illustrative). Each route has a tier; when
tier-1 latency rises toward its budget, lower tiers are rejected or served stale
first, so team saves and contest joins keep their capacity in the last minutes.
"""

TIER = {
    "POST /teams": 1, "POST /contests/join": 1,
    "GET /contests": 2, "GET /lineups": 2, "GET /teams/preview": 2,
    "GET /leaderboard/other": 3, "GET /feed": 3, "GET /recommendations": 3,
}
BUDGET_MS = 300       # tier-1 p99 budget


def admit(route: str, tier1_p99_ms: float) -> str:
    tier = TIER.get(route, 3)
    pressure = tier1_p99_ms / BUDGET_MS
    if tier == 1:
        return "ADMIT"
    if tier == 3 and pressure > 0.6:
        return "REJECT_RETRY_LATER"          # 503 with Retry-After and jitter
    if tier == 2 and pressure > 0.8:
        return "SERVE_STALE"                 # from cache, even if a version old
    return "ADMIT"

Deep Dive 2: Contest Joins and Spot Allocation (Week 1 Concepts: Hot Keys and Skew; Week 2: Idempotency)#

This builds on Week 1, Day 4 · Hot Keys and Skew and Week 2, Day 2 · Idempotency in Practice.

What is published: Dream11 reported more than 7.9 million entries in a single contest and 8,000 contest joins a second in IPL 2020, and that it serves "millions of contests in a single match", generated per match by a contest-generation engine. Its contest service caches contests in Aerospike and spreads the hottest keys by writing "10 duplicate copies" of them. Its team service runs Aerospike in strong-consistency mode; Aerospike's webinar with Dream11 describes it at over a million transactions a second.

%% title: One join: idempotent, sharded, never oversold
flowchart TD
  J["Join request<br/>join id, team, contest"]:::service
  IDEM{"Seen this join id?"}
  T{"Template or mega?"}
  OPEN["Current open copy<br/>next copy pre-created"]:::service
  SHARD["Spot shard, random<br/>take one if above 0"]:::hot
  DEB@{ icon: "sd:wallet", label: "Wallet debit<br/>same join id" }
  ENTRY@{ icon: "sd:database", label: "Entry row<br/>if match OPEN" }
  BACK["Give the spot back<br/>debit failed"]:::bad
  J ==> IDEM
  IDEM -->|"yes"| ENTRY
  IDEM ==>|"no"| T
  T -->|"small"| OPEN ==> DEB
  T ==>|"mega"| SHARD ==> DEB
  DEB ==> ENTRY
  DEB -.->|"declined"| BACK
  class DEB store
  class ENTRY store

• Exactness comes from the shards, not from a total. Each shard is a conditional decrement on one key; the sum of shard allotments is the contest size. There is no moment when two shards can both hand out the last spot, because there is no shared last spot.
• Spread the shards across nodes, not just across keys: 100 shards on 100 partitions turn 15,000 joins a second into 150 per key.
• Order matters: spot, then money, then entry. A spot held without money is cheap to return; money taken without a spot is a refund and a support ticket. If the debit fails, a compensating step returns the spot to its shard.
• The entry write checks the lock. A join that took a spot and debited at 7:29:59.9 but writes its entry at 7:30:00.1 fails the match-state check; the spot and the fee go back. Exactly what the deadline promised.
• Unfilled contests follow their rules. A contest that doesn't fill by the deadline is either guaranteed (it runs, smaller) or cancelled and refunded by reversing postings: a decision made per contest at creation and recorded on it.
• Duplicates by template, not by copying load. The contest-generation engine decides which templates exist for a match; each template keeps one open copy and a pre-created next one, so a full copy is never a user-visible error.

# contests/spots.py

"""
Taking one spot in a large contest (illustrative). Spots are split across shards,
each a key that can only be decremented while positive; the allotments sum to the
contest size, so the contest cannot be oversold. A join id makes retries safe.
"""

import random

TRIES = 3


class ContestFull(Exception):
    pass


def take_spot(kv, contest_id: str, shards: int, join_id: str) -> int:
    held = kv.get(f"join:{join_id}")
    if held is not None:
        return held                                       # a retry: same spot as before
    for s in random.sample(range(shards), min(TRIES, shards)):
        if kv.decrement_if_positive(f"spots:{contest_id}:{s}"):
            kv.set(f"join:{join_id}", s, ttl_s=3600)
            return s
    left = kv.sum_prefix(f"spots:{contest_id}:")          # rare: a near-full contest
    if left == 0:
        raise ContestFull(contest_id)
    s = kv.rebalance_into_one(contest_id)                 # move the stragglers together
    if kv.decrement_if_positive(f"spots:{contest_id}:{s}"):
        kv.set(f"join:{join_id}", s, ttl_s=3600)
        return s
    raise ContestFull(contest_id)


def give_back(kv, contest_id: str, join_id: str) -> None:
    s = kv.pop(f"join:{join_id}")
    if s is not None:
        kv.increment(f"spots:{contest_id}:{s}")           # debit failed or deadline passed

Deep Dive 3: Lock-Time Consistency (Week 5 Concepts: Consistency Models; Week 2: Distributed Cron)#

This builds on Week 5, Day 1 · Consistency Models and Week 2, Day 5 · Distributed Cron and Job Scheduling.

What is published: Dream11's 2017 leaderboard team wrote that it maintained a consistent view across platforms with "snapshot isolation", using insert-only operations and immutable datasets. Its IPL 2023 post lists new team creation rules and an "auto-substitutes" feature among that season's product changes.

%% title: A match's life, from fixtures to settlement
stateDiagram-v2
  [*] --> OPEN: fixture published
  OPEN --> OPEN: rain, deadline moved later
  OPEN --> LOCKED: scheduled start, one flip
  LOCKED --> LIVE: first ball
  LIVE --> COMPLETED: last ball
  LIVE --> ABANDONED: no result
  COMPLETED --> VERIFIED: scorecard checked
  VERIFIED --> SETTLED: prizes credited
  ABANDONED --> REFUNDED: entries reversed
  SETTLED --> [*]
  REFUNDED --> [*]
  class SETTLED ok
  class ABANDONED bad
  class LOCKED queue

• Version every team. A team edit writes version n+1 with the match version it saw; the lock flip bumps the match version, so a write carrying an old version fails even if it was delayed in a queue.
• Freeze into a snapshot. Right after the flip, a job reads every team's last committed version and writes an immutable table: lineup hash → players, captain, vice-captain, and entry → lineup hash. The points engine reads only this snapshot; the live team tables can't change it.
• Lock is a fence, not a broadcast. The lock job doesn't need every server to hear about it; the store rejects late writes. Caches of "match is open" can be stale for a second without harm, because they only decide what the app shows, never what is accepted.
• Never reopen. Information arrives after the start (the first ball). Moving a deadline earlier or reopening a locked match would let some users edit with knowledge others didn't have. Delays only move an open deadline later.
• Non-playing players. If a picked player doesn't play, he scores zero; a product rule like auto-substitutes (swapping in a pre-chosen backup at lock time) must also be applied in the snapshot job, once, by a deterministic rule recorded with the snapshot.
• Abandoned matches go to REFUNDED: every entry is reversed in the ledger by the same keyed postings used for joins.

# teams/save.py

"""
Saving a team edit (illustrative). The write is conditional on the match still
being OPEN at the version the client saw, checked atomically by the store, so no
server clock decides what counts as "before the deadline".
"""


class DeadlinePassed(Exception):
    pass


def save_team(store, match_id: str, user_id: str, team_no: int, lineup: dict, edit_id: str):
    validate(lineup)                                   # 11 players, 100 credits, per-side limit, C and VC
    m = store.get(f"match:{match_id}")
    if m.state != "OPEN":
        raise DeadlinePassed(match_id)
    ok = store.transact([
        store.check(f"match:{match_id}", state="OPEN", version=m.version),
        store.put_if_new_edit(f"team:{match_id}:{user_id}:{team_no}", lineup, edit_id=edit_id),
    ])
    if not ok:
        raise DeadlinePassed(match_id)                 # the flip committed first
    return {"saved": True, "server_time": store.now(), "deadline": m.deadline}


def lock_match(store, match_id: str):
    m = store.get(f"match:{match_id}")
    if m.state == "OPEN":
        store.compare_and_set(f"match:{match_id}", expect_version=m.version, state="LOCKED")
        enqueue("snapshot_lineups", match_id)          # freeze teams into lineups, once

Deep Dive 4: Live Points, Ball by Ball (Week 8 Concepts: Streaming vs Batch; Late Data)#

This builds on Week 8, Day 2 · Streaming vs Batch Processing and Week 8, Day 4 · Late Data.

Over 14.3, a four, then a correction. The batter hits a four and the feed sends it; forty seconds later it sends a correction: a leg-bye, so the runs go to the team, not the batter. Karthik's vice-captain is that batter. Here is how the design handles both events:

• Players first. The points engine keeps each of the 22 players' points as a function of the full ball-by-ball record, not a running sum: it recomputes the batter's and bowler's points from their ball records.
• Lineups by inverted index. At lock, build player → lineups. Only lineups containing a changed player are rescored: lineup points = sum of its 11 players' points, ×2 for the captain, ×1.5 for the vice-captain. Karthik's lineup moves by 1.5 × the batter's change.
• Corrections are just new versions. Each ball event has an id and a version. The correction replaces ball 14.3's record; the batter's points are recomputed from the corrected record, and the lineups and ranks follow. Nothing is "subtracted", so applying it twice changes nothing.
• Untouched lineups keep their totals: on a typical ball, two players change, so lineups containing neither don't move.

What is published: Dream11's leaderboard post (2017) describes points for "composition of up to 11 players selected from the squad and points scored by the players for every action", calculated by a point calculation engine ("Aryabhata") on Apache Spark that recomputes team points, groups them by contest, sorts and applies competitive ranking, updating "every minute across thousands of contests". Dream11's published points system gives the captain 2× and the vice-captain 1.5× their points.

%% title: From one ball to new ranks, each step done once per distinct thing
flowchart TD
  F@{ icon: "sd:stream", label: "Score feed<br/>ball 14.3, version 2" }
  P["Player points<br/>recomputed from ball records"]:::core
  IDX@{ icon: "sd:index", label: "Player to lineups<br/>built at lock" }
  LU["Lineup points<br/>sum of 11, C 2x, VC 1.5x"]:::core
  K@{ icon: "tech:kafka", label: "Kafka<br/>lineup deltas" }
  R@{ icon: "tech:spark", label: "Rank engine · Spark<br/>histogram, top list" }
  C@{ icon: "tech:redis", label: "Redis<br/>contest summaries, ball 14.3" }
  F ==> P ==> LU
  IDX -.-> LU
  LU ==> K ==> R ==> C
  class F external
  class IDX store
  class K queue
  class R service
  class C cache

• Ball records are the source of truth. Store every delivery as a versioned record; player points are a pure function of a player's records and the scoring table. Replays, corrections and a crashed worker all produce the same numbers.
• Order by ball, not by arrival. The feed may deliver 14.4 before a correction to 14.3. Because points are recomputed from the full record set, order doesn't matter for correctness; a per-match sequence number lets the rank stage tag its output "as of ball 14.4, version n".
• Points are discrete. Runs, wickets and catches are whole points; the vice-captain's 1.5× makes halves. So every lineup score is a multiple of 0.5. This matters for ranking (Deep Dive 5).
• Micro-batch per ball. Rather than streaming each lineup update into ranking separately, the rank stage runs once per ball (or every few seconds when balls come quickly), over all lineup deltas since the last run: one Spark job per ball, not millions of tiny updates.
• Coalesce under pressure. If ranking falls behind (two balls in 40 seconds plus a correction), skip intermediate states and rank the latest; users only ever see the newest consistent "as of" ball.

# points/lineups.py

"""
Rescoring lineups after one ball (illustrative). Player points are recomputed from
the versioned ball records; only lineups containing a changed player are touched.
Scores are kept in half-points as integers, since the vice-captain multiplier is 1.5.
"""

MULT2 = {"C": 4, "VC": 3, "P": 2}          # doubled multipliers: 2x, 1.5x, 1x


def player_points(records, scoring) -> dict:
    pts = {}
    for r in records:                       # every ball's latest version only
        for player, action in r.actions():
            pts[player] = pts.get(player, 0) + scoring[action]
    return pts


def rescore(changed: dict, old: dict, by_player: dict, lineups: dict, totals: dict) -> dict:
    """changed/old: player -> points now / before. Returns lineup -> new total (half-points)."""
    touched = set().union(*(by_player.get(p, ()) for p in changed))
    for lid in touched:
        role = lineups[lid].role_of           # player -> "C", "VC" or "P"
        totals[lid] += sum(MULT2[role(p)] * (changed[p] - old.get(p, 0))
                           for p in changed if role(p))
    return {lid: totals[lid] for lid in touched}

Deep Dive 5: Leaderboards at Scale: Approximate, Exact and Final (Week 1 Concepts: Hot Keys; Week 4: Feed Caching)#

This builds on Week 4, Day 4 · Feed Caching and Week 1, Day 4 · Hot Keys and Skew.

What is published: Dream11's 2017 leaderboard was built to "crunch gigabytes of data using distributed sorting" within an SLA of under a minute: teams "grouped by the participating contest, sorted by total points and ranked as per competitive ranking", for "around a million contests" of 2 to 400,000 teams, 40 million records, served at a peak of 1 million requests a minute to 250,000 concurrent users from a 10-node Cassandra cluster with Redis caching at the web servers.

• Rank from a histogram is exact, as long as buckets are as fine as the scoring step. If a game's scores were continuous, coarser buckets would give an approximate rank ("about 1,84,000"), which is fine during a match but not for prizes.
• Approximate is acceptable while live. Showing a rank "as of ball 14.3" that is one ball behind is fine; showing a wrong rank after settlement is not. The live leaderboard can be a little stale; the final one must be recomputed from the verified scorecard.
• Read path: a few cached lookups. A rank request reads the user's entries (lineup ids), their lineup totals and the contest's histogram for the current ball version; all three are cached in Redis, with the hottest contests' summaries copied to several nodes, as Dream11 did for its hottest contest keys.
• Small contests are cheap. A 2-person contest doesn't need a histogram; sort its entries. The histogram path is for the few large contests where sorting millions per ball costs too much.
• Push the change, not the table. The app polls a tiny "latest ball version" endpoint from the CDN and fetches ranks only when it changes; 15 million phones never re-download a leaderboard every few seconds.
• The final leaderboard is a separate, exact job. After the match is verified, rank every contest from the final lineup totals with a full sort and competitive ranking, write the ranks and tie groups once, and hand them to settlement.

# ranks/histogram.py

"""
Exact live ranks from a points histogram (illustrative). Scores are integers in
half-points (the vice-captain earns 1.5x), so a contest fits in a few thousand
buckets; competitive ranking falls out of a running sum from the top.
"""

MAX_HALF_POINTS = 3000          # 1,500 points, in half-points


def build(totals_of_entries) -> list:
    hist = [0] * (MAX_HALF_POINTS + 1)
    for s in totals_of_entries:
        hist[min(s, MAX_HALF_POINTS)] += 1
    above = [0] * (MAX_HALF_POINTS + 2)              # above[s] = entries with score > s
    for s in range(MAX_HALF_POINTS, -1, -1):
        above[s] = above[s + 1] + hist[s + 1] if s < MAX_HALF_POINTS else 0
    return above


def rank(above: list, score: int) -> int:
    return 1 + above[min(score, MAX_HALF_POINTS)]   # ties share the rank (1, 2, 2, 4)


def tied_prize(prizes: list, first_rank: int, tied: int) -> float:
    """Split the prizes for ranks first_rank .. first_rank+tied-1 equally among the tied entries."""
    window = prizes[first_rank - 1:first_rank - 1 + tied]
    return sum(window) / tied

Deep Dive 6: Wallet, Ledger and Winnings (Week 2 Concepts: Idempotency; Week 3: Audit Logs)#

This builds on Week 2, Day 2 · Idempotency in Practice and Week 3, Day 5 · Audit Log System.

What is published: the Finance Act 2023 taxes net winnings from online games at 30% (Section 115BBJ) and requires the platform to deduct tax at source on net winnings at the time of withdrawal and at the end of the financial year (Section 194BA, from 1 July 2023), computed by the formula in Rule 133 of the Income-tax Rules; from 1 April 2026 the Income-tax Act, 2025 carries the same deduction under Section 393(3), at the same 30% with no threshold. Separately, from 1 October 2023 GST on online money gaming has been levied at 28% on the full amount deposited by the player, rather than 18% on the platform's fee; money re-entered from winnings is not treated as a fresh deposit.

%% title: Money in, entry fees, prizes and tax, each a balanced posting
flowchart TD
  U@{ icon: "sd:card", label: "Deposit<br/>UPI or card" }
  GST["GST payable<br/>28% of the deposit"]:::service
  DEP@{ icon: "sd:wallet", label: "Deposit balance<br/>user's own money" }
  POOL["Contest pool<br/>fees held until settled"]:::core
  LED["Ledger<br/>append-only, keyed"]:::hot
  WIN@{ icon: "sd:wallet", label: "Winnings balance<br/>prizes credited" }
  TDS["TDS payable<br/>30% of net winnings"]:::service
  BANK@{ icon: "sd:bank", label: "User's bank<br/>withdrawal" }
  U ==> LED
  LED --> GST
  LED --> DEP
  DEP ==>|"join"| POOL
  POOL ==>|"settle"| WIN
  WIN ==>|"withdraw"| BANK
  WIN --> TDS
  class U client
  class DEP,WIN store
  class BANK external

• Three balances, one ledger. Deposits, winnings and bonus are separate accounts per user; a join debits them in a fixed order (a product rule, recorded on each posting), so the tax formula can always tell deposits from winnings.
• The contest pool is an account. Entry fees move into the contest's pool, minus the platform fee. Settlement moves the pool to winners. The pool must reach zero, and the sum of credits must equal the published prize table, before the contest is marked settled.
• Every posting is keyed. Joins by join id, prizes by (contest, entry, settlement version), refunds by (contest, entry, "refund"), withdrawals by withdrawal id. A replay or retry finds the key and does nothing.
• Corrections are new versions. If a verified scorecard is later corrected before settlement, the final ranks are recomputed and settlement runs with version 2; nothing posted for a version is ever edited. Once settled, a later change is a business decision handled by new postings, not a rewrite.
• Tax is a query, then a posting. At withdrawal, sum the user's withdrawals, deposits and already-taxed net winnings for the financial year from the ledger, apply the formula, and post the TDS in the same transaction as the withdrawal.
• Reconcile three ways every day: deposits against the payment gateway's settlement files, withdrawals against the bank's payout reports, and contest pools against prize tables. Anything unmatched is a ticket.

# wallet/withdraw.py

"""
A withdrawal with tax deducted at source on net winnings (illustrative). Net
winnings for the financial year follow the prescribed formula; the TDS, the user
debit and the payout instruction are posted together under one withdrawal key.
"""

from decimal import Decimal

TDS_RATE = Decimal("0.30")


def net_winnings(withdrawn_fy: Decimal, deposits_fy: Decimal, opening: Decimal, taxed_fy: Decimal) -> Decimal:
    return max(Decimal(0), withdrawn_fy - (deposits_fy + opening + taxed_fy))


def withdraw(ledger, user: str, amount: Decimal, wid: str, fy: str):
    if ledger.exists(key=f"wd:{wid}"):
        return ledger.get(key=f"wd:{wid}")                 # a retried request
    agg = ledger.fy_aggregates(user, fy)                   # sums of the user's postings this year
    nw = net_winnings(agg.withdrawn + amount, agg.deposits, agg.opening, agg.taxed)
    tds = (nw * TDS_RATE).quantize(Decimal("0.01"))
    with ledger.tx():
        ledger.post(key=f"wd:{wid}", entries=[
            (f"user:{user}:winnings", -amount),            # the user's balance goes down by the full amount
            ("tds_payable", tds),                          # owed to the government
            ("payouts_in_transit", amount - tds),          # what reaches the bank
        ])
        ledger.mark_taxed(user, fy, nw)
    return {"paid": amount - tds, "tds": tds}

Karthik's Match Night#

Edge Cases#

Monitoring Dashboard#

SLOs for a Match Night#

The interviewer leans back. "One more."

Summary: Concepts Applied from 10-Week Course#

Why Dream11 Matters#

Self-Assessment Checklist#

After studying this case study, you should be able to:

The spike and the joins:

The lock and live points:

Leaderboards and money:

Sources#

Dream11 and Dream Sports:

• Blog

  Dream11 Engineering — IPL Fever: How Dream11 serves 10.56 million+ users during the TATA IPL 2023 (10.56 million concurrent at the opener; 308 million requests a minute, "about five million requests per second"; microservices for authentication, user, team, contest and leaderboard; auto-substitutes), 2 May 2023: https://tech.dream11.in/blog/ipl-fever-how-dream11-serves-10-56-million-users-during-the-tata-ipl-2023

• Blog

  Qamar Ali Shaikh and Ritesh Sharma — To Scale In Or Scale Out? Here's How We Scale at Dream11 (100 million+ users; 5.5 million+ concurrency; 100 million+ requests a minute at edge services; 30,000+ compute resources; 100+ microservices; XGBoost concurrency forecast over 200+ variables; Scaler; Game Days), Dream11 Engineering, 2 April 2021: https://tech.dream11.in/blog/2021-04-02_To-Scale-In-Or-Scale-Out--Here-s-How-We-Scale-at-Dream11-f88ef5e71cbc

• Blog

  Srijan Gupta and Anuj Gupta — How does Dream11 serve millions of Personalised Contests in a match (surge in contest joins after the toss; ~5 million concurrency post-toss; contest generation engine; VoltDB, Spark Streaming, Aerospike; 10 duplicate copies of hot keys), Dream11 Engineering, 12 January 2021: https://tech.dream11.in/blog/2021-01-12_How-does-Dream11-serve-millions-of-Personalised-Contests-in-a-match-cbb00463b7da

• Blog

  Amit Mirchandani, Amit Sharma and Bharat Vishwakarma — Leaderboard @Dream11 (points per action for up to 11 players; Aryabhata point engine on Apache Spark; competitive ranking; leaderboards updated every minute; around a million contests of 2 to 400,000 teams; 40 million records within a 60-second SLA; 1 million requests a minute at 250,000 concurrent users; Cassandra; Redis; snapshot isolation with insert-only, immutable datasets), Dream11 Engineering, 24 October 2017: https://tech.dream11.in/blog/2017-10-24_Leaderboard--Dream11-4efc6f93c23e

• Blog

  Sanket Raut, Vatsal Shah, Ritesh Sharma and Eeshan Bembi — How Dream11 uses an in-house scaling platform (forecast 5 days ahead, updated 2 hours before, scaling from 1 hour before instead of 3; a forecast once almost doubled to ~10 million; 700+ auto-scaling groups and 200 load balancers; ~245 million requests a minute at edge services vs ~69 million at a non-edge service; scaling in about five minutes; 100+ sporting events a day), AWS for Games Blog, 20 September 2023: https://aws.amazon.com/blogs/gametech/how-dream11-uses-an-in-house-scaling-platform

• Read

  Aerospike — How Dream11 built a fantasy sports team service to handle futuristic IPL scale (strong-consistency mode; over a million transactions a second), webinar: https://aerospike.com/resources/webinars/how-dream11-built-a-fantasy-sports-team-service-to-handle-futuristic-ipl-scale/

Reporting:

• Read

  Sportskeeda — Dream11 Points System (T20: captain 2× and vice-captain 1.5× points; 100 credits per team): https://www.sportskeeda.com/cricket/dream11-points-system

• Book

  Entrepreneur India — Dream11 Reports 5.3 Mn-plus Concurrent Users During Ongoing IPL Season (5.3 million+ concurrent on 14 October 2020; 60 million requests a minute; 8,000+ contest joins a second; 18 million+ contestants in a single match; 7.9 million+ entries in a single contest; comments by CIO Abhishek Ravi), 28 October 2020: https://india.entrepreneur.com/news-and-trends/dream11-reports-53-mn-plus-concurrent-users-during-ongoing/358644

• Book

  Inc42 — Dream11 Shines On IPL Debut, Onboards 1.1 Mn New Users (15.01 million concurrent users on the first day of IPL 2024, posted by CEO Harsh Jain on X), 22 March 2024: https://inc42.com/buzz/dream11-shines-on-ipl-debut-onboards-1-1-mn-new-users/

• Read

  TechCrunch — As India bans real-money games, Dream Sports, MPL start pulling the plug (Parliament's passage on 20 and 21 August 2025; operators suspend real-money games), 21 August 2025: https://techcrunch.com/2025/08/21/as-india-bans-real-money-games-dream-sports-mpl-start-pulling-the-plug

• Wiki

  Wikipedia — Dream11 (200 million users in October 2023; paid contests, over 90% of revenue, paused in August 2025; free-to-play since): https://en.wikipedia.org/wiki/Dream11

Law and regulation (India):

• Wiki

  Promotion and Regulation of Online Gaming Act, 2025 (passed 20 and 21 August 2025; assent 22 August 2025; prohibits offering and advertising online money games): https://en.wikipedia.org/wiki/Promotion_and_Regulation_of_Online_Gaming_Act,_2025

• Read

  MediaNama — Online Gaming Rules Notified, In Effect From May 1, 2026 (rules notified 22 April 2026; in force 1 May 2026; Online Gaming Authority under MeitY), April 2026: https://www.medianama.com/2026/04/223-online-gaming-rules-notified-may-1-major-changes/

• Read

  Supreme Court Observer — Challenge to the Promotion and Regulation of Online Gaming Act, 2025 (High Court challenges transferred to the Supreme Court on 8 September 2025; pending): https://www.scobserver.in/cases/challenge-to-the-promotion-and-regulation-of-online-gaming-act-2025/

• Read

  Kashmir Observer (PTI) — SC agrees to hear pleas challenging new online gaming law (final hearing agreed on 5 August 2026), 5 August 2026: https://kashmirobserver.net/2026/08/05/sc-agrees-to-hear-pleas-challenging-new-online-gaming-law/

• Blog

  Taxmann — 28% GST shall be levied on online gaming and casinos w.e.f. 1.10.2023 (CBIC notifications of 29 September 2023; 28% on the amount deposited): https://taxmann.com/post/blog/28-gst-shall-be-levied-on-online-gaming-and-casinos-notification

• Book

  Mondaq — Net Winnings From Online Games: Calculation Prescribed By CBDT (Rule 133 formulas for net winnings at withdrawal and at year end; Section 194BA from 1 July 2023), 19 April 2024: https://www.mondaq.com/india/income-tax/1452742/net-winnings-from-online-games-calculation-prescribed-by-cbdt

• Blog

  TDSMAN — TDS on winnings from lottery, games, etc. (Section 194BA carried into Section 393(3) of the Income-tax Act, 2025 from 1 April 2026), May 2026: https://blog.tdsman.com/2026/05/tds-on-winnings-from-lottery-games-etc-section-3933-section-194b/

Design note: the architecture, code, thresholds, dashboards and every number labelled as an assumption or estimate are an illustrative design for the problem, not a description of Dream11's internal systems beyond what Dream11 has published. Users per match, teams per user, entries per team, the share of joins after the toss, distinct lineups, the final's figures and the tax example are assumptions. Tax and regulatory facts are summarised for engineering context, are not legal or tax advice, and should be checked against current law.

Further Reading#

Related systems to study:

• Read

  IRCTC Tatkal (Bonus Problem 11 in this series): a scheduled spike at a known time, with admission control

• Read

  BookMyShow (Bonus Problem 16): seats that must never be sold twice, under a flash crowd

• Read

  Razorpay (Bonus Problem 18): payments, settlement and reconciliation from the provider's side

• Read

  Zerodha Kite (Bonus Problem 13): a market-open spike at 9:15, and exactly-once orders

Course material:

• Talk

  The course's Hotstar case file covers the other half of an IPL night: streaming the match itself to 25 million viewers

Foundational concepts (this course):

• Read

  Week 1, Day 4 — Hot Keys and Skew

• Read

  Week 2, Day 2 — Idempotency in Practice

• Read

  Week 2, Day 5 — Distributed Cron and Job Scheduling

• Read

  Week 3, Day 3 — Backpressure and Flow Control

• Read

  Week 3, Day 5 — Audit Log System

• Read

  Week 4, Day 3 — Thundering Herd

• Read

  Week 4, Day 4 — Feed Caching

• Read

  Week 5, Day 1 — Consistency Models

• Read

  Week 8, Day 2 — Streaming vs Batch Processing

• Read

  Week 8, Day 4 — Late Data

• Read

  Week 10, Day 4 — Capacity Planning

"Decide the deadline in one place, score each distinct thing once, and rank by counting."