Section 10: Seven Ways to Break a Sorted Map - Interviewer Deep-Dive Challenges

Executive Summary: The interviewer spends the last stretch trying to break the design. Each answer follows one pattern: a number from Section 3's napkin, a mechanism Sections 5 to 9 already built, what it costs, and what would make you change your mind. Three of the seven attacks are won in the row key, not the engine. Two are won by pointing at the real budget: Chubby takes ~47% of the error budget and server crashes take ~1%, so the expensive fix for crashes is aimed at the wrong number.

The interviewer leans back. "It reads fast and it's sized. Now let me break it."

Challenge 1: The Timestamp Key

"A new click-analytics tenant keys every row by event time. What happens?"

You: "Every write lands on the tablet that owns the end of the keyspace. One server takes the whole tenant at its ~5,000 ops/s ceiling while 999 sit idle. Splitting on load doesn't help. The tablet splits, the left half goes cold, and the new tail is just as hot as the old one. The fix goes in the row key. The Bigtable paper's own Google Analytics table keyed each session row by website name plus session creation time. That's field promotion: writes spread across every active site, and a per-site time range is still one contiguous scan. Salting, a small hash-bucket prefix, spreads writes too, but a time-range query becomes one scan per bucket, merged."

The engine stays range-partitioned (D2). Promote a field when queries are per-site; salt only when the dominant query is "everything in this window" and no natural leading field exists.

The senior line: "Hot spots in a sorted map are a key-design bug. I fix them in the application's row key, not by making the engine hash."

Quick check before moving on: