Section 9: Stretch the Interval Until It Snaps - Interviewer Deep-Dive Challenges

Executive Summary: The design is on the board and the live edge has survived Section 8. Now the interviewer pushes on every assumption it rests on: a city five times hotter than planned, events lasting hours or weeks, a cheaper engine, a question the index was never built for, a query 100 times too big, and data not everyone should see. Each escalation gets three beats: the interviewer's line, an answer that starts from a Section 3 number, and the sentence a senior engineer leaves on the table. Two of the six answers are "the index is the wrong tool", and saying so is the point.

The interviewer leans back. "Good. Let's see where it bends." Find the number that decides each challenge, name the mechanism, and say when you would switch.

Challenge 1: New Year's Eve in the Largest Market

"It's New Year's Eve. Your largest market runs at five times its normal peak. What breaks?"

Partition size breaks first. The largest partition at a normal peak is λ(B + D) = 2,083 × 35 ≈ 73K rows ≈ 15 MB. At 5× that becomes ≈ 73 MB, past the 50 MB sub-shard trigger from Section 5. Total writes stay small; one partition just gets too large.

The fix was planned in Section 5's partition-key decision, and it is planned, not reactive. NYE is on the calendar, so a week ahead we write a shard-map entry: city = largest, shards = 4, effective_from = 2026-12-31T18:00Z. From that bucket onward the indexer writes to hash(event_id) mod 4, and each partition drops to ≈ 18 MB. A 30-minute window there reads 3 buckets × 4 shards = 12 partitions, inside the 16-in-flight budget. Older buckets are untouched: nothing is rewritten or migrated, and the emit rule still holds.

The senior line: "Hot partitions are a scheduling problem when the spike is on the calendar: split forward from an effective-from bucket and never rewrite the past."