Design fantasy sports contests (Dream11)

Most joins happen in the last minutes, and a mega contest instance with 2M spots receives thousands of joins per second. A single database row with spots_filled would be a hot row. Use an atomic counter in Redis per contest instance (remaining spots), claimed with DECRBY; a negative result means full, so increment back and try the next instance. Because contest templates are fungible (users want 'a ₹49 contest with this prize structure', not a specific instance), the service auto-creates a new instance when one fills, which spreads the load and avoids a 'contest full' error. The wallet debit must be tied to the spot: claim the spot, debit with an idempotency key, and on debit failure release the spot. If the service crashes between the two, a reconciler compares claimed spots with debits and fixes them, so the Redis counter is fast but not the source of truth; the entry rows and ledger are. Entries are written asynchronously via Kafka to the sharded database, so the user path stays fast. At the deadline, the contest service flips match status to LOCKED in a config pushed to every node, and requests after that are rejected by server time.

Naively, every ball triggers a recalculation of 200M+ entries. The trick is to see that a team's score is a weighted sum of 11 player points (captain 2x, vice-captain 1.5x), and that there are far fewer distinct teams than entries: popular combinations repeat millions of times, so dedupe by team_hash. Pipeline: the points calculator turns each feed event into player point deltas (only 22 players matter) and publishes a versioned PointsChanged event. A distributed job (Spark, Flink or plain workers over partitions of unique teams) recomputes scores for unique teams containing changed players and writes them under the new version. Entries do not need their own score; they reference their team. This turns the problem into ~tens of millions of small dot products per event, which takes seconds on a modest cluster. Debounce: if several events arrive within a few seconds, process the latest version only. The user's 'my teams' view reads the team scores directly, so points feel live even when ranks lag a little.

Exact rank in a 2M-entry contest after every ball is expensive and unnecessary. Use different strategies by contest size. Small contests (2 to ~10k entries): a Redis sorted set per contest; ZREVRANK gives exact rank cheaply. Giant contests: compute ranks in periodic batches (every 30-60 s) using a score histogram. Scores are discrete (multiples of 0.5), so bucket entries by score; a user's rank is 1 + the number of entries with a higher score, a prefix sum over the histogram. The histogram for a contest is built from team-score counts weighted by how many entries use each team, which is cheap with the team_hash dedupe. Exact top-100 pages come from a sorted set of the leading entries only. Show 'rank is updating' instead of wrong ranks during recomputation, and version every snapshot so a client never mixes scores from one ball with ranks from another. Final ranks for settlement are computed once offline, exactly, with tie rules, and are the only ranks that move money.

Money must be right even if the job crashes halfway. Settlement starts only after the match result and points are final, because data providers send corrections (a catch re-credited to another fielder) after the match. For each contest, compute final scores and exact ranks, then apply the prize table with tie handling: if three entries tie for ranks 4-6, they share the sum of prizes for 4, 5 and 6 equally. Write planned payouts to a settlement table first, verify totals per contest equal the prize pool (a hard check), then execute ledger credits in batches where each credit uses idempotency key = entry_id. Rerunning the job is safe: already-credited entries are skipped. For contests that did not fill and are not guaranteed, refund all entry fees with the same idempotent pattern. Large winnings may need tax deduction and withdrawal checks, handled by separate flows. Keep an immutable audit trail of inputs (points version, prize table) used for each contest.

A database row with conditional update is the simplest correct answer but becomes a hot row under thousands of joins/s per contest. A Redis counter is fast and atomic; its weakness is durability, solved by treating entries and ledger as truth and reconciling. Auto-creating instances reduces contention further.

Exact ranks after every ball for every giant contest cost a lot and users do not need them second by second. Exact ranks for small contests and periodic histogram ranks for giant ones give a good experience at a small fraction of the cost. Final ranks are always exact.

Match schedules are known weeks ahead, and the spike rises in minutes, faster than autoscaling reacts. Pre-scale compute, databases and caches per match tier an hour before, based on forecasts, and scale down after. Autoscaling remains a backup.

Every join debits a wallet; a user joining 20 contests in one minute creates contention on their balance row. Shard the ledger by user_id, keep each debit a single-row conditional update plus an insert, and batch multiple joins from one request into one debit.

Every wicket sends millions of users to refresh. Serve player points and team scores from Redis and CDN with short TTLs keyed by version; leaderboards serve precomputed pages. Degrade by slowing rank refresh before affecting scoring.

Lineups are announced at the toss, ~30 minutes before the match, and millions of users edit teams at once. Teams are partitioned by user, writes are idempotent replacements, and validation is in memory with cached rules.

Use two data providers and compare; a scorer console lets operators correct events. Points are versioned, so a correction simply produces a new version and scores recompute. Settlement waits for a verified final version.

Replica promotion may lose the last few decrements. A reconciler recounts entries per instance from the database and fixes the counter; if an instance is overfilled, the extra entries are moved to a new instance of the same template before the deadline, or refunded.

Mark the match ABANDONED and run the refund flow over all entries with idempotent ledger credits. Users see the refund in their wallet; nothing is settled.