1Context and scope
Design the shopping side of Amazon: a shopper opens the home page, searches, reads product pages, adds items to a cart and places an order that is later shipped. Reads dominate: for every order there are dozens of searches and product views, so the read path must be cheap and fast at the 99th percentile and beyond. The write path is small but unforgiving: a cart must accept every add, stock must not be oversold, a card must not be charged twice and a placed order must never be lost. Traffic is spiky: Prime Day and Lightning Deals multiply load for hours and concentrate it on a few products. This doc goes deeper than the Amazon storefront case study: it is how a strong candidate runs the hour, with the numbers, the API, the data model and the trade-offs an interviewer probes.
2Clarifying questions
- Which parts of Amazon are in scope?
- The buyer storefront: home, search, product pages, cart, checkout and order status. Sellers, ads, warehouses and delivery are out of scope.
- How big is it?
- Assume 50 million shoppers a day, 20 requests each: 1 billion requests a day, about 11,600 a second on average and 23,000 at the daily peak. 2% are checkouts: 20 million orders a day.
- How spiky is traffic?
- Prime Day is about 4× the daily peak for hours, and Lightning Deals concentrate demand on a few products for minutes. Design for 93,000 requests a second and hot keys.
- One region or global?
- One large marketplace in one region across several availability zones, split into cells. Multi-region is a follow-up.
- When is stock promised?
- Not at add-to-cart. Stock is reserved when the order is placed, for a limited time, and confirmed when payment is authorised. Product pages show availability as a hint.
- How are payments handled?
- Through an external processor with tokenised cards: authorise at order time, capture later (for example at shipment). Card numbers never touch our services, which shrinks PCI scope.
- How fresh must prices and search results be?
- Seconds for price and availability changes, minutes for new products. The price charged is the one re-read at checkout, not the one cached on a page.
- Can shoppers check out as guests?
- Browsing and the cart work signed out (keyed by session); checkout requires an account. Guest carts merge into the account cart at sign-in.
3Goals and non-goals
Goals
- Home page with deals and personalised recommendations; images and scripts from a CDN.
- Keyword search with filters (facets), sorting and pagination.
- Product page: details, price, availability, review summary and “customers who bought this also bought”.
- A cart that is always writeable, kept across devices and visits.
- Checkout: reserve stock without overselling, authorise payment exactly once, create the order.
- Every order reaches fulfilment and notifications; shoppers see order status and history.
Non-goals
- The seller side (listing products, seller pricing tools) and advertising.
- Warehouse operations, routing and delivery after the order is handed to fulfilment.
- Training recommendation and ranking models (we use their outputs).
- Tax, fraud and payments internals beyond calling a payment processor.
- Multi-region active-active writes for orders (discussed as a follow-up).
5Capacity estimate
| Quantity | Value | How |
|---|---|---|
| Shoppers a day | 50 million | an assumption for the exercise, not an Amazon figure |
| Requests a day | 1 billion | 50 million × 20 requests that reach the services (pages and API calls; images counted separately) |
| Average and daily peak | ≈ 11,600/s and ≈ 23,000/s | 1 billion ÷ 86,400 s; the daily peak is about 2× the average |
| One cell (the lab) | 2,000 req/s | about a dozen identical cells at the daily peak: 500 home, 600 search, 600 product, 200 cart, 40 checkout, 60 order status a second |
| Prime Day | ≈ 93,000 req/s site-wide, 8,000 per cell | 4× the daily peak; pre-scale cells, or add cells, before the event |
| Orders | 20 million a day | 2% of requests: ≈ 230/s average, 460/s daily peak, 1,850/s on Prime Day |
| Catalog records | 5 TB | 500 million products × 10 KB, before replication; images ≈ 800 TB in object storage (8 images × 4 sizes × 50 KB) |
| Image egress | ≈ 78 Gbit/s at the daily peak | 85% of 23,000 req/s are page views × 500 KB of images ≈ 9.8 GB/s, all from CDN edges |
| Product cache | 100 GB, 90% hit rate | hottest 10 million products × 10 KB; the 90% hit rate is an assumption of skewed (Zipf) popularity |
| Cart writes | 2,300/s, 9,200/s on Prime Day | 10% of requests; keyed by customer, so spread evenly over partitions |
| Cost of one cell | ≈ $46,200 a month (budget $65,000) | payment fees ≈ $29,600 of it; CDN ≈ $6,100, WAF ≈ $3,100, egress ≈ $2,100, emails ≈ $1,000, everything else ≈ $4,300 (illustrative prices) |
The rest of the doc
Non-functional requirements · API · Data model · The design · Deep dives · Key concepts · Alternatives considered · Failure modes and fixes · Interviewer follow-ups · Common mistakes · What a strong answer covers · Try it in the lab · Check yourself · Further reading
Unlock “Design Amazon: the full interview”
The full interview: clarifying questions, estimates, API, data model, the design, deep dives with trade-offs, follow-ups, common mistakes and a rubric. Unlocking it also unlocks the build problem in the lab. Paid once, on your account.