Section 12: The Final Standings - Final Summary & Candidate Scorecard
Executive Summary: This closing section turns the module into a grading instrument. We replay the interview section by section and name the signal each phase was recording, then give a 100-point scorecard weighted toward deep-dive depth, because this problem is won on the write path and the scale-out, not on the diagram. Each dimension says what a top score sounds like for Rift Runners and where points leak. A sixty-second close shows the whole design in one breath, score bands map totals to readiness with targeted remediation, and a final catalog shows where the same "a max, an index and an incentive" question hides in other loops.
Go back to minute five. Someone in the room said ZADD and ZREVRANK, and for one board at 50 million daily players that answer was right. That was the trap. The interviewer was never scoring whether you knew sorted sets. They were scoring whether you could say why the simple answer is right, how much load it carries, and where it stops being right. The candidate who stopped at two commands gave the correct answer and earned almost none of the points. The scorecard below records the six things a Staff candidate adds: the proof that it fits, the max, the tie rule, the log underneath, the defense against cheaters, and the flip trigger.
The Arc, Replayed as Signal
| Section | What you did | Signal the interviewer recorded |
|---|---|---|
| 1. Problem Understanding | Asked best or cumulative, how ties break, whether there are prizes, whether the client is trusted | Found the max, the tie and the incentive before drawing a box |
| 2. Requirements | Submit → ranks p99 ≤ 300 ms, others' changes visible ≤ 2 s, reads at 99.9% but run acceptance at 99.95% | NFRs a test could verify; the game plays without the board |
| 3. Scale Estimation | 500M runs/day → ≈ 17,400 runs/s peak → ≈ 35,000 runs/s design peak; 34,800 ops/s per board primary at peak, 70,000 at surge, against a 100,000 budget; weekly replicas at 50,400 ops/s (≈ 25,200 each); 15 GB all-time | Proved one sorted set per board fits, and that the ceiling is per-board CPU, not memory |
| 4. API Design | POST /v1/runs submits a run with a runId and a server-signed run ticket and returns both ranks; paging capped at rank 10,000; me resolved from the token |
The client submits evidence, never a score; read-your-writes for free |
| 5. Data Modeling | lb:weekly:2026-W44, composite = score × 2^29 + (2^29 − 1 − t) with t = max(endedAt, ticketIssuedAt + durationMs), player_best with a conditional update, Kafka partitioned by playerId |
Ties settled in the encoding; "why not Postgres?" answered with order statistics |
| 6. Architecture | Run Validator, Score Service (appends to Kafka run-results, then calls the board applier), Best-Score Writer, a read API with a 1 s in-process top-100 cache |
Every absence defended: no SQL rank, no per-user friends set, no multi-primary |
| 7. Write Path | Lua running ZADD GT CH + ZREVRANK on one node; Kafka first with acks=all, RF 3, min.insync.replicas=2, unclean leader election disabled; one board applier for the live path, failover replay and rebuild; rebuild in 5 min |
The max makes retries, replays and reordering harmless, behind an applier that skips provisional, banned and removed runs |
| 8. Beyond One Node | ×10: 700,000 ops/s per board → 8 score-range shards at ≈ 87,500 ops/s each; rank = Σ ZCARD of higher shards + local ZREVRANK; each move committed by a compare-and-set on the player directory, strays swept by an hourly reconciler |
Chose range over hash (8 ZCOUNTs per rank) and said when to switch |
| 9. Challenges | Primary dies Sunday 20:59; 5-minute grace; a run arriving 00:07 gets 200 with weekly: {status: "season-closed"} and counts for all-time only, while 422 is kept for invalid runs; spectators get top-100 diffs |
Composure; escalations answered with numbers and rules |
| 10. Anti-Cheat & Reliability | zzz_speed's 9,999,999 in 41 s (243,902 pts/s) rejected; top-1,000 entries provisional for ≤ 15 min; shadow bans; RTO ≤ 10 min | Treated the board as an incentive and planned for failure |
| 11. Evolution | Country boards at +50% write ops; materialized clan boards; a rolling 7-day board kept current by live ZADD GT and rebuilt daily from per-day bests, off the hot path |
New features as additive consumers; the max still holds |
Key Insight: Read the right-hand column and notice how many rows are the same observation at different depths: a best score is a max. It is why GT is safe to retry, why Kafka replay after a rebuild can overlap the table snapshot, why late runs cost nothing extra to apply, and why live ZADD GT keeps a rolling board current. The exception is removal, a delete rather than a max, so every replay goes through the board applier's verdict and ban filter. One algebraic fact, found in the first five minutes, pays rent in almost every section.
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson