1Context and scope
A storefront is mostly browsing: product pages, search and recommendations. Carts change constantly but are small. Checkout is rare and must be right: stock must never go negative, a payment must not run twice, and the order must be fulfilled even if the email provider is down. This design covers browse, cart and checkout at browser scale, based on Amazon’s published architecture work (Dynamo, the Builders’ Library).
2Goals and non-goals
Goals
- 4,000 requests a second: 70% browsing, 20% cart updates, 10% checkouts.
- Success at least 99%, p99 at most 1.5 s (checkout waits on a payment), zero lost updates.
- Orders are fulfilled through a queue; nothing is lost and nothing runs twice.
Non-goals
- Sellers, listings and the marketplace.
- Logistics after the order is placed.
- Pricing and promotions.
3Capacity estimate
| Quantity | Value | How |
|---|---|---|
| Browsing | ≈ 2,800/s | 70% of 4,000; the CDN serves half the reads |
| Product cache | 64 GB, 50M products, 2 h TTL | Zipf 1.1: popular products dominate |
| Search | ≈ 840/s | 30% of browse: 512 slots, 4 ms CPU on 48 vCPU |
| Recommendations | ≈ 1,400/s | 50% of browse: 1,024 slots, 3 ms CPU on 64 vCPU |
| Checkouts | ≈ 400/s | each: an atomic stock update, a payment (350 ms), a queued fulfilment job |
| Payments | 400 × 0.35 s ≈ 140 slots busy | 2,000 slots; 2% declines; a backup service takes failures |
The rest of the doc
The design · Key concepts · Alternatives considered · Failure modes and fixes · Try it in the lab · Check yourself · Further reading
Unlock the Amazon storefront design doc
Every component and why it is there, the capacity numbers behind it, what breaks when you push it and how to fix it, and the same system open in the lab to break and fix yourself. Paid once, on your account.