Section 13: The Judges' Table - Final Summary & Candidate Scorecard

Executive Summary: This closing section turns the module into a way to grade yourself. It replays the twelve sections as the signals the panel was recording, lays out a 100-point scorecard with Bigtable-specific phrases for what earns and loses points, sets three calibration rules and four score bands that each point to the sections to redo, and lists the prompts that are this interview in disguise.

The panel never graded the box labeled "tablet server." They listened for whether you heard "structured data" and reached for joins, whether your arithmetic turned 500 TB into a million tablets and a 1 GB METADATA table before you drew the master, and whether, when a server died at 10:00:00, you said "its Chubby session expires at about 12 s, the master deletes its lock file, 64 log segments are sorted in parallel, and 0.1% of the keyspace is back at about 20 s" rather than "another node takes over."

The Arc, Replayed as Signal

The chart is the arc; what earned the signal at each step was the number said out loud:

• Sections 1–5: the scan question answered before any box; 99.99% stated as 8.64 s a day; 400 servers derived and 1,000 chosen for 2.5× headroom; MutateRows called atomic per row, not all-or-nothing.
• Sections 6–9: a tablet move as a pointer move; 3 round trips, up to 6 when stale; lock-file deletion as the fence; recent: from memory, history: misses pruned by Bloom filters at ~1%.
• Sections 10–12: every escalation with mechanism, number and flip trigger; the 10:00:00 death walked second by second; Chubby named as ~47% of the error budget.

Key Insight: None of those signals is "has read the Bigtable paper." The panel tests whether you know which mechanism keeps which promise: the commit log on 3 racks keeps writes durable, the Chubby lock keeps one server per tablet, immutable SSTables make splits and moves cheap, the three-level hierarchy keeps the master off the read path, and the row key keeps scans local.