Amazon System Design Masterclass
Deconstruct the systems powering the world's largest retail platform. Learn how Amazon ensures high-availability shopping carts, executes write sharded transactions on **DynamoDB key spaces**, locks multi-warehouse inventories atomically, and reconciles transactions asynchronously using Lambda streams.
The E-Commerce Settlement Challenge
At massive scale, e-commerce architectures must balance two conflicting requirements: **maximum availability** during client shopping (users must be able to add to their cart even under network partition events) and **strict ACID consistency** during ledger inventory commits (you cannot sell the same physical unit to two different buyers). Hot-spots on items, partition-level database choking, and latency during peak shopping events (like Prime Day) are highly common issues that require robust distributed ledger designs.
Core Challenges
- • Continuous Cart availability: Carts must never fail to add items, even if a datastore datacenter collapses.
- • Hot-Spot Throttling: Distributing millions of concurrent writes on extremely popular items to prevent database partition lockups.
- • Warehouse Allocations: Locking stock allocations across multiple warehouses without introducing latency.
- • Double-Entry Ledger: Guaranteeing that checks, debits, and inventory writes settle atomically with audit trails.
Expected Scale Parameters
Distributed Carts High-Availability Replication
To guarantee shopping cart availability even during complete datacenter network drops, Amazon prioritizes write capability over immediate database consistency. This is historically modeled on **Dynamo Key-Value Storage**, employing **eventual consistency, Vector Clocks, and client-side conflict resolutions**.
Eventual consistency shopping cart design:
Carts prioritize **high availability** over immediate consistency using Dynamo parameters:
- Dynamo Key-Value Write: Adding an item to the shopping cart performs a low-latency write to the closest geographical active zone (e.g. US-East).
- Vector Clocks: Rather than overwriting existing records, changes are versioned using vector clocks (e.g. `[node_A: 1, node_B: 2]`).
- Sibling Creation: If a network partition occurs between datacenters A and B, a user can write to both datacenters concurrently. The database preserves both entries as "siblings" instead of throwing error codes.
- Client-Side Convergence: When the connection restores and the user opens their cart page, the client application reconciles siblings (e.g. combining items added to both partitions) and writes the unified cart back to the database, achieving eventual consistency.
Multi-Warehouse Inventory Allocation & Locks
While shopping carts operate on eventual consistency, inventory allocations at checkout require **strict consistency**. You cannot allow two users to purchase the last physical Kindle unit in a warehouse simultaneously. To manage this, Amazon utilizes an active **distributed locking allocation engine**.
Strict Inventory Allocations
When checkout is initiated, the **Inventory Allocator** selects the closest warehouse containing active stock of the purchased item.
To lock the allocation, the engine attempts to acquire an **in-memory distributed lock** on that warehouse's item SKU using Redis (Redlock). This short-lived 10-second lock prevents race conditions. If the transaction completes successfully (i.e. payment settles), the inventory count is decremented on DynamoDB and the lock is committed; if payment fails or timeouts occur, the lock is released instantly to return stock to available pools.
Dynamic Order Ledger Settlement (ACID Commits)
Settling e-commerce transactions requires absolute transactional integrity. Order creation, credit card capture, and inventory decrement writes must succeed as a single atomic unit. Amazon solves this using highly sharded **Two-Phase Commit (2PC) Transactions** combined with double-entry ledger bookkeeping.
Atomic Settlement Commits
To commit ledger changes atomically, the **Transaction Coordinator** initiates a two-phase process:
- **Phase 1 (Prepare):** The coordinator asks both database partitions (Order Book and Inventory Log) to reserve resources and lock the records, returning an active "Prepared" acknowledgement.
- **Phase 2 (Commit):** If both partitions acknowledge successfully, the coordinator pushes a "Commit" signal, writing both transactions to disk. If any database fails to acknowledge (or a network drop occurs), a "Rollback" signal is broadcast instantly, returning all resources to their original state and preserving ACID ledger consistency.
Asynchronous Reconciliation Pipeline
While checkout transactions are synchronous, downstream operations (warehouse dispatches, financial accounting updates, and seller payouts) are decoupled into an **Asynchronous Reconciliation Pipeline** powered by SQS queues and Lambda stream processors.
Decoupled Downstream Pipelines
If checkout processes must wait synchronously for warehouse inventory updates, shipping labels creation, and financial bookkeeping modifications, checking out would take minutes and buckle the core systems.
To prevent this, Amazon decouples downstream updates into an **Asynchronous Reconciliation Stream**.
Once checkout settles, a secure transaction event is published to highly available **AWS SQS queues**. **Lambda stream processor nodes** read SQS logs, dispatching independent async jobs to initiate warehouse packaging, verify dynamic tax parameters, compute seller payouts, and write entries to double-entry financial databases.
Expert Interview Q&A
Prepare for elite system design loops. Study the exact technical database sharding and cart replication questions and production-ready answers.
Q1. How does the system handle "hot-spot" partition throttling on extremely popular items?
Answer: By appending a random synthetic suffix (e.g. `_0` to `_9`) to the DynamoDB **Partition Key (PK)** hash values. This shards the write load across 10 physical storage partitions, avoiding partition write limits. The query engine reads partitions in parallel and aggregates indices in the application layer.
Q2. Why is eventual consistency selected for shopping carts over strict consistency?
Answer: To guarantee high availability. Prioritizing write capability over immediate consistency ensures users can add items to carts even under network partition drops. Versioned records are tracked using vector clocks, and conflicts are resolved on the client-side at page loads.
Q3. How does the system prevent double-selling the last physical item in a warehouse?
Answer: By executing checkout allocations under in-memory distributed locks in **Redis (Redlock)**. When a warehouse is selected, the engine acquires a 10-second lock on the SKU. If payment completes, the inventory count decrements on DynamoDB; if it fails, the lock is released instantly.
Q4. How are accounting and shipping updates managed without inflating checkout times?
Answer: Downstream operations are decoupled into an **Asynchronous Reconciliation Stream**. Checkout writes publish transaction events to **AWS SQS queues**, which decoupled **Lambda stream nodes** read to execute warehouse dispatch and balance calculations asynchronously.
Unified End-to-End Checkout & Settlement Map
Below is the ultimate, unified architecture topology powering Amazon's checkout and inventory settlement. It traces shopper checkout clicks to sharded DynamoDB nodes, Redlock inventory allocations, 2PC coordinators, and decoupled Lambda SQS queues.
Checkout & Fulfillment Journey: Step-by-Step
High-Availability Shopping Cart Ingress
Adding items to shopping carts performs a low-latency write to the closest geographical active zone (e.g. US-East). Versioned records are tracked using vector clocks, and conflicts are resolved on the client-side at page loads, guaranteeing high availability even under network partitions.
Checkout Ingress Gateway & Rate Limiter
Tapping "Proceed to Checkout" opens a secure session via regional gateways. Ingress gateways decrypt SSL, authorize user sessions, and check rate-limiting tokens under 3ms.
DynamoDB Sharded Write Execution
Checkout requests publish to sharded DynamoDB partitions. Adding synthetic suffixes (e.g. `_0` to `_9`) to popular item Partition Keys shards writes across 10 physical storage partitions, avoiding write throttle limits.
Distributed Inventory SKU Allocation
The allocator identifies the closest warehouse containing the purchased stock. To prevent double-selling, a short-lived **Redis distributed lock (Redlock)** is acquired on the SKU key during the transaction.
Two-Phase Commit (2PC) Ledger Settle
Order ledger and stock count updates commit in an atomic two-phase commit: Phase 1 prepares resource locks on database shards; Phase 2 executes the write commit upon secure credit card capture.
Asynchronous SQS Event Broadcast
Once the commit is acknowledged, a checkout event publishes to secure **AWS SQS queues**, decoupling long-latency downstream processes from the synchronous client loop.
Lambda Downstream Fulfillment Settle
**AWS Lambda stream processors** consume SQS logs, dispatching independent async jobs to calculate taxes, update double-entry financial journals, compute seller commissions, and initiate physical packaging at fulfillment centers.