</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

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

Executive Summary: The design is finished and defended; now the interviewer tries to break it. Eight escalations arrive, from shard 17 dying at 18:59:30 to a bidder demanding proof he lost, 2,000 bids a second on one auction, and an increment-table change while auctions are live. Each gets the same two-step answer: right-size the threat against Section 3's numbers and Section 2's service levels, then range over the responses that cost justifies, naming the alternative declined and the trigger that would flip it. Three of the eight are not bid-path problems at all, and saying so aloud is the strongest signal in the room.

Section 9 ended with the marker changing hands. The interviewer is no longer asking whether the design works but where it is thin and how much thickness each threat deserves. Every escalation is a lure; bite on all eight and you end the hour with a consensus protocol guarding one row that handles 200 bids a second.

Key Insight: The interviewer grades the two-step, not the answer: bound the threat, choose the smaller tool, and name the number at which the bigger one becomes necessary.

Eight escalation challenges mapped to the component each one stresses: Auction Store shards, Bid Ledger, Proxy Engine and Hot-Item Owner, Hot-State Cache and Gateway

Challenge 1 - Shard 17 Dies at 18:59:30

"Ten thousand auctions on that shard are in their final minute. What happens?"

Right-size: every acknowledged bid is already on the synchronous replica in the second availability zone - that was the price of the 200. Promotion takes roughly 10 to 30 seconds; meanwhile bids on shard 17 get a 503 with Retry-After: 0 and clients retry with the same idempotency key, so nothing is double-counted or lost. The cut-off is untouched: accepted_at < end_time is evaluated inside the transaction. Anyone whose only bid would have landed in those 30 seconds lost their chance - a product policy, not a protocol: a blip this short is absorbed; longer outages fall under Section 11's extension rule. Range: a Sotheby's-grade lot enters hot-item mode early, where the row is only a flush target, and takes the standby-region log replica Section 11 describes into its quorum, so a dead shard delays a flush and a dead region costs 80 ms a verdict, not the lot. Signal: you knew what the sync replica bought and did not invent a bid to be kind.

The diagram follows Dana, who is bidding not on #7731 but on #7740, a vintage Leica camera on the same shard, ending at the same second.

Sequence of shard 17's primary dying at 18:59:30: Dana's bid gets a 503, the replica is promoted at 18:59:45, the retry with key k1 commits as HIGH_BIDDER, a duplicate retry returns the stored verdict, and the closer finalises at 19:00:31

Quick check before moving on:


Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.