Amazon E-commerce

Online shopping

Design an online store where people search a huge catalog, keep a cart on every device, and check out without the store selling stock it does not have or charging anyone twice.

Overview

An online store has two very different halves. Browsing (product pages, search, the cart) is almost all reads and must never be down: a shopper who cannot add to the cart simply leaves. Buying (checkout, payment, stock) is a small fraction of the traffic, but it moves money and physical goods, so it must be correct: no item sold twice, no card charged twice, no order lost.

A good interview answer keeps these halves apart and gives each the right tools: caches, replicas and always-available stores for browsing; transactions, conditional writes and idempotency keys for buying. The interviewer usually then pushes on three spots: the cart, overselling during a deal, and what happens when a step of checkout fails halfway.

Questions to ask first

How many shoppers and orders? — 100 million daily active shoppers; 10 million orders a day
How big is the catalog? — About 500 million products
How spiky is traffic? — Sale days reach 10 times the normal peak; single deals draw thousands of buyers a second
Can we oversell? — No. A confirmed order must have stock behind it
Does the cart hold stock? — No. Stock is reserved at checkout, for a few minutes
Payments? — An external payment processor; we authorize, then capture

What you will be able to do

Explain why a page built from many services needs each service to be fast at the 99.9th percentile.
Design a cart that accepts writes during failures, and merge its versions without losing adds.
Prevent overselling with conditional writes and short reservations, including for one very hot item.
Walk through checkout as a saga with compensations, made safe to retry by idempotency keys.
Plan for a sale day: pre-scaling, queues and shedding load.

Key concepts

Catalog read path
Tail latency
Always-writable cart
Cart merge
Stock reservation
Hot items
Checkout saga
Idempotency keys
Load shedding

Functional requirements

View a product page with price and availability
Search the catalog with text and filters
Add, change and remove cart items from any device, signed in or not
Check out: reserve stock, pay, and receive an order number
See order status as it moves from confirmed to shipped

Non-functional requirements

Product pages load in under 300 ms at p99 (a target we chose)
Add to cart always succeeds, even during a data center or network failure
Never confirm an order without stock; never charge a card twice for one order
Absorb 10 times the normal peak on sale days
A confirmed order is never lost

Interview questions

How do you prevent overselling?
Why not reserve stock when an item is added to the cart?
How does the cart stay available during failures?
Walk through checkout. What happens if payment fails?
How do you make sure a customer is charged once?
How would you handle Prime Day?
Why is page latency measured at the 99.9th percentile?
Which data goes in a relational database and which in a key-value store?