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...

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."

🏛️ Scenario 2: Design Distributed Order Fulfillment Pipeline (Saga Pattern & Idempotency)

A. The Challenge

• Requirement: Complete an order involving Order Creation, Payment Charging, Warehouse Inventory Allocation, and Notification dispatch across independent microservices.
• Failure Modes:
  1. Two-Phase Commit (2PC) locks database tables across services, causing latency cascading and catastrophic deadlocks.
  2. Network timeout during payment: did the payment succeed or fail?

B. Architecture Solution

Synthesizing vector architecture diagram...

C. The Distributed Techniques

1. Orchestrated Saga with AWS Step Functions:
   • Avoid distributed database transactions (2PC). Each microservice executes its own local transaction in its own database.
   • AWS Step Functions orchestrates the sequence. If Step 3 (Payment) fails, Step Functions executes Compensating Transactions in reverse order (e.g., ReleaseInventory and CancelOrder).
2. Idempotency Token at Every Boundary:
   • Every request carries an Idempotency-Key: <UUID> generated by the client.
   • The Payment Service stores processed keys in DynamoDB with a conditional write: attribute_not_exists(IdempotencyKey).
   • If a timeout occurs and the client retries, the Payment Service detects the existing key and returns the previously processed transaction status without double-charging.

D. The 3-Axis Trade-off Defense

• Maintainability Defense: "We chose an Orchestrated Saga via AWS Step Functions over a Choreographed (event-driven) Saga. In an e-commerce fulfillment pipeline with complex compensation paths, choreography leads to 'spaghetti event flows' where understanding system state requires distributed tracing across 10 event queues. Step Functions visualizes the entire execution DAG, providing centralized error handling and observable state."
• Performance Trade-off: "Orchestration introduces a centralized coordinator, adding ~20-50ms overhead per step compared to direct asynchronous messaging. For an order fulfillment workflow spanning several seconds, this latency is imperceptible to the user."
• Cost Defense: "Step Functions Express Workflows cost $1.00 per million executions, making it extremely cost-effective compared to maintaining custom workflow orchestration engines on EC2."

🏛️ Scenario 3: Design Global Distributed Key-Value Store (DynamoDB Internals)

A. The Challenge

• Requirement: Provide a global, multi-tenant distributed key-value store supporting millions of QPS with $<10\text{ms}$ latency and tunable consistency.

B. Architecture Solution

Synthesizing vector architecture diagram...

C. The Distributed Techniques

1. Consistent Hashing with Virtual Nodes:
   • Partition keys are hashed using MD5/SHA-256 onto a 128-bit circular ring.
   • Each physical storage node is mapped to 200 virtual nodes (Vnodes) on the ring to guarantee uniform data distribution and avoid "hot fingers."
2. Sloppy Quorum & Hinted Handoff:
   • If a primary replica node is down during a write, the write is accepted by an alternate healthy node with a "hint" in its metadata indicating the intended destination.
   • When the primary node recovers, the alternate node delivers the hinted data back (Hinted Handoff), maximizing write availability.
3. Tunable Quorums ($R + W > N$):
   • With replication factor $N = 3$:
     • Read Quorum $R = 2$, Write Quorum $W = 2$.
     • Since $R + W = 4 > 3$, the read set and write set always overlap by at least one node, guaranteeing strong consistency.
     • If the client chooses $R = 1$ and $W = 1$, the system operates as high-availability eventual consistency ($AP$).

⏱️ The 45-Minute Amazon Interview Execution Blueprint