Section 10: The Escalation Gauntlet - Interviewer Deep-Dive Challenges

Executive Summary: The design is finished and defended; this section is the interviewer trying to break it. Seven escalations arrive — a region loss mid-saga, a search stampede, a 40-room wedding block, the oversold guest in the lobby at 11 p.m., a stale OTA cache, "prove you never oversold", and a guest who moves her dates — each answered with the same two-step: right-size the threat against numbers you derived, then range over the responses they justify. Two of the seven are deliberately not systems problems, and recognising that is the strongest signal here: an honest bound beats an invented protocol.

Escalations are lures, phrased to make maximum machinery sound obvious — strike at every one and you end the hour with a consensus protocol guarding 28 booking writes per second. Right-size first: what does the threat cost, in the numbers from Section 3 and the SLOs in Section 2? Then range: the response that cost justifies, the alternative you decline, and the measurement that would change your mind.

Challenge One - A Region Goes Down Mid-Booking

"Dana has a hold, you've called the payment provider, and the region hosting her property's shard disappears. What happens to her booking?"

Walk the saga's state machine from Section 7 through the failure. Holds are durable Postgres rows, not Redis entries (D5 — a Redis-only hold vanishes on failover, leaving an oversell or leaked inventory, and the leak is worse because nothing errors). Each property shard runs its second-AZ standby plus a synchronous replica in its paired region — 10–30 ms RTT, comfortably inside the 500 ms hold budget — and it is that out-of-region replica, not the AZ standby, that survives a lost region: it inherits every hold at RPO zero, and promotion restores that shard's booking path in 30–60 seconds (D10). It is still single-writer per shard, so nothing here reopens the global active-active writes D10 declines — the replica is exactly what D10 pays for that 30–60 s RTO. Search never notices: it is active-active and read-only. A chain-wide booking outage costs about $182,000 a minute, so a 30-to-60-second RTO confined to one property's shard is a rounding error against it.

The hard state is the authorisation in flight, because a timeout says nothing about whether the card was charged. You never guess: resend the same idempotency key, learn what already happened, then commit or compensate. What is lost: in-flight requests during promotion fail, and Dana retries. The rejected alternative, global active-active booking writes, needs per-booking consensus (latency on every write) or last-write-wins (an oversell with no error anywhere), and 28 writes per second buys neither. D10's flip trigger: active-active writes per property, or a booking path past roughly 50,000 writes per second.

Quick check before moving on: