Amazon: the store that never closes
On Prime Day 2025, DynamoDB tables behind Amazon's systems peaked at 151 million requests a second. Amazon is the giant closest to your own business: a retailer with carts, stock, orders and warehouses. This lesson shows how its cart, inventory and order systems are built from public sources, and builds the stock reservation you would actually use.
By the end you can
- Explain Amazon's service rule: every team owns its data and exposes it only through an API
- Trace a checkout across cart, pricing, inventory, payment and order services
- Explain why the Dynamo cart was "always writeable" and how conflicting carts are merged
- Design DynamoDB keys for orders and lines, and reserve stock with a conditional write
- Decide what to copy at a few hundred stores, and what to leave alone
The everyday picture
Think of a big Mangrove Market store on the night before a festival. The front of the store has one rule: never stop a customer from putting something in the basket. If the shelf label is wrong or the scanner at aisle 4 is down, the customer still picks up the item; you sort it out at the counter. A basket that refuses an item loses a sale and annoys a customer.
The back of the store has the opposite rule: never promise a carton that is not there. When a partner shop orders the last 12 cartons of oil, exactly 12 orders may succeed, not 13. Each section of the store also runs itself: the bakery has its own staff, its own stock sheet and its own window where other sections place requests. Nobody walks into the bakery's storeroom and takes flour. That is Amazon: a basket that always says yes, a stock count that never lies, and many small teams that talk only through their windows.
What the product must do
- Functional. Browse a huge catalogue, add to cart from any device, see a price, check out, reserve stock in the right warehouse, take payment, create the order, and hand it to fulfilment. Show "only 3 left" and never sell the fourth.
- Non-functional. Pages fast at the slowest tail, not on average: the 2007 Dynamo paper describes service targets measured at the 99.9th percentile, such as 300 ms for 99.9% of requests (p99 and SLOs). The cart must accept writes even while servers or links fail. Stock and payments must be exact. Peaks like Prime Day are many times a normal day.
- Organisational. Hundreds of teams must ship independently without breaking each other.
At Amazon the organisation came first, and the architecture followed it.