Section 9: The Escalation Gauntlet - Interviewer Deep Dive Challenges

Executive Summary: This section confronts the closing phase of the interview, where the interviewer escalates deliberately — viral traffic, cascading failure, multi-region demands, Byzantine faults, silent data corruption — to test whether your judgment survives pressure. We establish the two-step answer pattern that defuses every escalation (right-size it with a number, then demonstrate range with a named mechanism), then run the full gauntlet: five challenges, five model responses, including the rare case where declining the premise is the winning answer. This is the section where the module's meta-lesson — scale-appropriate judgment, backed by range — faces its final examination.

The architecture is drawn, the deep dives survived, and the interviewer's expression changes. What follows is not curiosity; it is choreography. "What about Byzantine failures?" "Traffic jumps a thousandfold — walk me through it." "The VP wants multi-region by Q3." Each question arrives glittering with an invitation to perform — to reach for consensus protocols and global replication and prove how much vocabulary you own. And each contains a hook, because the interviewer has spent an hour watching you establish that this is a 120-QPS, 60-megabyte internal tool, and now they are testing whether you still know it under pressure. Candidates who strike at every shiny escalation reveal that their judgment can be baited. Candidates who dismiss the questions flatly reveal they cannot scale up when scale is real. The passing lane runs precisely between.

Key Insight: Every escalation is answered twice. Step one — right-size it: does this problem exist at our measured scale? Say so, with the number. Step two — show the range: name the mechanism you would deploy at the scale where it becomes real, and the trigger that would tell you it's time. One answer demonstrates judgment; the other demonstrates depth; together they are unanswerable.

Challenge One: The Thousand-Fold Spike

"Your service gets mentioned at the all-hands and traffic jumps 1000×. What breaks first?"

Step one — the number. A thousand times our peak is 120,000 QPS. First observation, delivered calmly: most of that wave never reaches us, because the page is static and lives on the CDN — edge infrastructure that serves hundreds of thousands of requests per second as its ordinary business. What reaches the backend is API calls from authenticated internal users, of whom exactly 100,000 exist:

Claimed spike:        120,000 QPS against the API
Reality check:        100,000 total registered humans
                      120,000 QPS = every user, refreshing, in sync — implausible
Plausible worst case: all 10,000 DAU sign in within 10 minutes
                      10,000 × 3 reads ÷ 600 s ≈ 50 QPS … within existing headroom

Noticing that the premise fails arithmetic — before solving it — is itself the signal being tested.

Step two — the range. Suppose it becomes real: the tool goes public. The absorption is layered, and mostly already built: the CDN swallows the front; gateway rate limits shed the abusive tail; serverless concurrency scales the legitimate middle — with the platform ceiling named aloud (Lambda's default account concurrency sits near 1,000, raisable by ticket; knowing where your platform's ceilings live is Staff hygiene); and DynamoDB on-demand absorbs order-of-magnitude jumps, with the honest caveat that it throttles on instant doublings while warming capacity over minutes. The one genuinely new component: the short-TTL read cache whose trigger Section 6 named in advance. No re-architecture — four dials and one pre-authorized addition.