Amazon System Design Interview Scenarios & Answers

The Bar Raiser Standard: In an Amazon System Design interview, the interviewer does not just grade whether your diagram works. They evaluate your ability to think like an Owner and an Architect—anticipating edge-case failures, preventing cascading collapses, and proactively articulating the trade-offs of your choices.

🏛️ Scenario 1: Design Amazon Prime Day Flash Sale (Extreme Concurrency & Hotspots)

A. The Challenge

• Requirement: 500,000 users attempt to purchase a limited inventory item (1,000 units of a discounted Sony TV) at 12:00:00 PM.
• Failure Modes:
  1. Traditional relational databases crash due to row-level lock contention (SELECT ... FOR UPDATE on stock_count).
  2. Single partition key bottleneck in NoSQL (PK = "ITEM#123" throttles at 1,000 WCU).
  3. Thundering herd overwhelms the payment gateway.

B. Architecture Solution

Synthesizing vector architecture diagram...

Follow 500,000 shoppers from the top. CloudFront serves the waiting-room page from S3 (1), so browsing never touches the backend, and only order submissions (2) pass WAF's rate limits into API Gateway and the intake Lambda. In the "Sub-millisecond Atomic Reservation" panel, a Redis Lua script checks and decrements stock in a single atomic step, so two buyers can never both get the last item, and the result is written to 10 sharded DynamoDB counters in the next panel for durability. Only successful reservations produce a token that enters the SQS FIFO queue, where fulfillment workers take payment at the pace Stripe allows. The spike is absorbed in memory; everything after the reservation runs at a controlled rate.

C. The Distributed Techniques

1. Virtual Waiting Room & Rate Limiting:
   • CloudFront serves a static HTML/JS waiting room hosted in S3.
   • AWS WAF enforces rate limits (e.g., max 5 requests/10s per IP) to block automated scalper bots.
2. Atomic Inventory Reservation in Memory (Redis + Lua):
   • Do NOT write to the database synchronously on the request path!
   • An in-memory ElastiCache Redis cluster evaluates an atomic Lua script:

     luaCopy
     local stock = tonumber(redis.call('get', KEYS[1]))
     if stock > 0 then
         redis.call('decr', KEYS[1])
         return 1 -- Success
     else
         return 0 -- Sold out
     end

   • Lua executes atomically in a single Redis thread, reserving stock in $<1\text{ms}$ with zero lock contention.
3. Write Sharding the Database Counter:
   • If updating DynamoDB directly, a single item (stock_count) caps at 1,000 writes/sec.
   • Write-Sharding Pattern: Split the 1,000 stock into 10 distinct items: ITEM#123_SHARD_0 to ITEM#123_SHARD_9 (each holding 100 stock). A randomized hash directs requests across the 10 shards, multiplying throughput by $10\times$ (10,000 writes/sec).
4. Asynchronous Order Processing (SQS FIFO):
   • Users who successfully reserve a stock token receive 202 Accepted with a temporary reservation valid for 10 minutes.
   • The actual order placement and credit card charge execute asynchronously via SQS FIFO to protect the payment gateway from sudden traffic spikes.

D. The 3-Axis Trade-off Defense

Synthesizing vector architecture diagram...

• Performance Defense: "We moved the critical inventory deduction path to an in-memory Redis cluster running an atomic Lua script. This eliminates disk I/O and row-level locking bottlenecks, delivering P99 latency under 3ms."
• Cost Defense: "Because the flash sale only lasts 2 hours, we provision a high-memory ElastiCache cluster for the peak window and scale it down immediately after, avoiding long-term provisioned database costs."
• Maintainability & Reliability Trade-off (Concession): "The trade-off is eventual consistency between Redis and the authoritative database. If a Redis node crashes before flushing state, there is a risk of inventory discrepancy. We mitigate this by enabling Redis Multi-AZ with automated failover and running an asynchronous reconciliation worker that reconciles Redis reservations against DynamoDB completed orders."