Design Amazon

A 500 M-product marketplace: product pages at 100 k views/s, carts that never lose an item, and Prime Day checkout without overselling.

Last updated 2026-10-26. Difficulty: hard. Patterns: shopping-cart, inventory, caching, saga, aggregation. Reported at Amazon, Walmart, Shopify, eBay, Instacart.

Functional requirements

• Browse and search the catalogue. Hundreds of millions of products whose attributes differ completely by category, with faceted filters. Results come from a search index built from catalogue changes; ranking is out of scope.
• Product page with price, availability and a delivery date. Assembled from several teams’ services. It must stay fast when one of them is slow, and show a price and stock state that checkout will rarely contradict.
• Products with variants. A parent product (a shirt) with child SKUs (size × colour), each its own unit of price and stock, with the variation dimensions defined by the category.
• A cart that follows the buyer. Works signed out (a guest cart) and signed in, across devices, for weeks. The guest cart merges into the account cart at sign-in. Adding to the cart never reserves stock.
• Check out. Address, a shipping option with a promised date, and payment, at an authoritative price. One click on Place order produces exactly one order, however often it is retried.
• Never sell stock that is not there. Stock sits in about 100 warehouses. Reserve it when the order is placed, release it if the order fails, and do it without one hot row per product.
• Fulfil each order from the right warehouses. Chosen after the order is placed: the cheapest plan that still meets the promised date, which may split one order into several shipments.
• Order status and cancellation. Status per shipment. Cancelling before a shipment leaves releases its stock, and nothing that never shipped is charged.
• Out of scope. Search and recommendation ranking, seller tools and choosing between several sellers’ offers (one offer per SKU here), returns, warehouse operations, and payment internals: payment is a call to the payment service.

Non-functional requirements

• Product page latency (p99 < 250 ms server-side). The page waits on about six reads owned by different teams, so without deadlines its latency is the slowest one’s. A widget that misses its budget is replaced or dropped, never waited for.
• Read scale (100 k pages/s · 600 k reads/s). About 350 backend reads per order at the sale peak. No product page read may land on a system that checkout depends on, apart from a catalogue lookup on a cache miss.
• Freshness of price and stock (page < 5 s · checkout exact). The page may be a few seconds behind; the quote may not. Cart and checkout re-read the authority, so a stale page costs the buyer a message, never a wrong charge.
• Cart availability (99.99 %, no lost items). Add to cart is the step closest to revenue that needs nothing scarce, so it must keep working when other parts of the site are degraded.
• No oversell from concurrency (0 races · residual < 0.1 %). Physical counts are sometimes wrong (damaged or mislaid units), so a small residual is handled by policy: re-source, backorder or cancel. This drives the hardest tradeoff: an exact count per SKU against one deal SKU taking thousands of reservations a second.
• Place order (exactly once · p99 < 2 s). Most of the budget is the payment authorization. A retry, a double click or a crashed worker returns the same order, never a second one.
• Sale-day surge (10× orders at a known time). The spike arrives in seconds and autoscaling reacts in minutes, so capacity is raised beforehand, checkout is admitted at the rate payments can take, and recommendations are shed before anything on the path to an order.

Back-of-envelope estimates

• Orders per second: ~170/s · ~1.7 k/s on a sale day. 10 k orders/min ÷ 60 ≈ 170/s; 10× at a sale-day peak is ~1.7 k/s. At ~2.5 lines per order that is ~4 k reservations a second at the peak. Spread over hundreds of millions of stock rows this is easy; the hard part is the few SKUs everyone wants at once.
• Backend reads for product pages: ~600 k/s. 100 k page views/s × ~6 reads each (product document, price, stock, reviews, two recommendation widgets) = ~600 k reads/s, against ~1.7 k orders/s: about 350 reads per order at the peak. This is the number the caches and views exist for.
• Catalogue size: ~10 TB. 200 M parent products (500 M SKUs) × ~50 KB of attributes, text and variant data, images excluded = ~10 TB, ~30 TB with three replicas. Too big for one machine and only ever read by key, so a document store sharded by product id.
• Hot product cache: ~100 GB for ~90 % of reads. Views follow a steep power law: the top ~1 % of products (2 M) take about 90 % of page views. 2 M × 50 KB = ~100 GB, a small cache cluster. The long tail misses and costs one key lookup in the store.
• Price and stock views: ~45 GB, complete. 500 M SKUs × ~50 B of price data = 25 GB; 200 M stocked SKUs × ~100 B of per-region stock flags = 20 GB. Small enough to hold every SKU, so these are complete views kept current by events, not caches that miss to a system of record.
• Price changes: ~600/s. ~50 M price changes a day across the catalogue ÷ 86 400 ≈ 600/s. A 60 s TTL instead would refetch every SKU viewed in the last minute, say 5 M, every minute: ~80 k/s to the price service, and still up to a minute stale. Pushing changes is both cheaper and fresher.
• Carts: ~400 GB · ~5 k adds/s. 200 M live carts, signed-in and guest, × ~2 KB = ~400 GB. About 5 % of product views add to cart: 100 k × 0.05 = ~5 k adds/s at peak. A small, write-heavy key-value problem where availability matters far more than capacity.
• Busiest stock row on a deal: ~1 k reservations/s. A popular deal draws ~3 k reservations/s in its first minute. It is stocked in 10 warehouses, but the one nearest the largest metro takes about a third: ~1 k/s on one row, twice what a contended row serves at low latency (~500/s). Split into 10 sub-counters, each takes ~100/s.

Components

• Web / app: Loads the product page shell from the CDN and the dynamic buy box from the API, so the expensive part of the page is cached and the fresh part is small. Holds the guest cart id in a long-lived cookie until sign-in. Sends the checkout id as the idempotency key on Place order and polls the order rather than resubmitting.
• CDN (shell 10 min · images 1 yr): Caches the product page shell (title, images, bullets, variant picker) per product and locale, and every image under a content-hashed URL. Price, stock and anything personal are deliberately left out of what it caches, so a cached page can be minutes old without ever showing a wrong price. Listing changes purge by product id.
• API gateway (auth · routing · admission): Authenticates the session, routes page, cart and checkout calls, and applies per-route rate limits. On a sale day it is where load is shaped: optional traffic is shed first, and Place order is admitted at the rate checkout and the payment service can take, with a short queue instead of errors.
• Page aggregator (parallel reads · budgets): Builds the dynamic part of a product page from about six parallel reads, each with its own deadline and fallback, inside a 250 ms server budget. Required parts (document, price, stock) fall back to stale or coarse values; optional parts (reviews, recommendations) are dropped. It never calls a system of record on the page path except the catalogue on a cache miss.
• Catalogue store (document per product): One document per parent product, keyed by product id, with its variants (SKUs) inside and its attributes validated on write against the category’s schema in a schema registry: a TV must have a screen size, a shirt has size and colour. About 10 TB, sharded by product id, read only by key. Search and browse come from an index built from its change stream.
• Reviews & recs (other teams · optional): Review summaries and recommendation widgets, owned by other teams and called with tight budgets (60 ms and 80 ms). They make a page better, not possible, so they are the first thing dropped on a slow call or a sale day. Recommendations fall back to a precomputed best-seller list for the category.
• Price service (authoritative prices · quotes): The source of truth for each SKU’s price, scheduled deal prices and promotions. Publishes every change with a version and an effective time to the event bus, which keeps the price view current. Computes the authoritative quote for the cart page and checkout, the only price a buyer is ever charged.
• Read caches (docs · price + stock views): Two kinds of data with different rules. Product documents are a true cache: ~100 GB of the hottest 2 M products, keyed by id and version, filled on a miss. Prices and per-region stock flags are complete views of every SKU (~45 GB) written from change events, so they never miss and are seconds fresh.
• Cart store (key-value doc per cart): One durable document per cart, keyed by user id or by a random guest id from a cookie: lines with SKU, quantity and the price seen when added. Changed by operations (add, set quantity, remove) applied with a version check, so two devices’ edits both land. Never holds stock and never treats its stored price as truth. Guest carts expire after 30 days idle.
• Checkout & orders (quotes · saga · order store): Prices the cart and the checkout with authoritative calls, then runs Place order as a durable saga: record the order, reserve stock, authorize payment, commit, mark placed. Owns the order store (relational, sharded by customer id) with orders, shipments, the saga’s step log and an outbox table, so each state change and its event commit together. Captures payment per shipment.
• Event bus (Kafka · keyed by entity): Order events from the order store’s outbox (keyed by order id), price changes and stock flips (keyed by SKU). Consumers are the view updaters, the fulfilment planner, search indexing, emails and analytics. Keying by entity keeps each SKU’s and each order’s events in order, which lets a view apply versions monotonically.
• Payment service (another team’s boundary): Authorizes at Place order, captures per shipment and voids on cancellation, keyed by order id or shipment id so retries are safe. Its internals (providers, idempotency store, ledger, unknown outcomes) are the Payment System design; here it is a boundary with an agreed sale-day quota. A timeout from it is an unknown, resolved by asking again with the same key.
• Inventory service (reserve · commit · release): Answers which warehouses can ship a line by when, and owns reservations: soft with a 10-minute expiry at Place order, then committed to the order or released. Every change is a conditional update on one stock row, so correctness never depends on callers behaving. Publishes stock flips (in stock, low, out) per warehouse, not every unit.
• Fulfilment planner (warehouse choice · splits): Consumes order.placed and chooses where each line really ships from: the cheapest plan that meets the promised date, one box when one warehouse has everything and a split when not. Moves reservations when its plan differs from checkout’s, releases shipments to warehouses, and reports each one back to the order service. Re-sources or backorders a line a warehouse cannot find.
• Inventory DB (row per SKU × warehouse): One row per SKU per warehouse (on hand, reserved, available) plus reservation records: about 500 M rows and 50 GB, partitioned by SKU so a SKU’s warehouses and reservations share a shard and every transaction stays on one. Rows of SKUs flagged hot for a sale are split into sub-counters. Relational, because the design leans on conditional updates and small transactions.

User flows

1. Sign in, check out, place the order. The main write path. The guest cart merges into the account, checkout prices everything from the authority, and Place order runs as a saga: record, reserve, authorize, commit. Every step is idempotent, so a retry or a crash repeats nothing.
   1. The buyer signs in with items in a guest cart; the guest cart merges into the account cart. Union of lines; the same SKU in both carts sums its quantities, capped at the item’s purchase limit, and the buyer sees a short "we merged your carts" notice. The guest cart is marked merged_into the account cart, so a repeated sign-in or a retried call cannot merge twice.
   2. The buyer opens checkout; the checkout service reads the cart and asks the price service for an authoritative quote. This is where price stops being a hint: the list or deal price at this second, promotions and coupons, the buyer’s eligibility, shipping and tax for the address. The quote has an id and a 15-minute expiry, and any line whose price moved since it was added is shown as changed before the buyer can pay.
   3. Shipping options and delivery dates come from current stock near the address, without reserving anything. The inventory service answers "which warehouses near this address can ship these lines, by when" from read replicas. Nothing is held yet: many buyers who reach this page never place the order, and holding stock for them would hide it from buyers who will.
   4. The buyer clicks Place order; the order is recorded as pending under the checkout id before anything else happens. Intent is durable before any side effect: order id, quote, address, shipping option and payment method go into the order store with status pending, together with the saga’s first step record. A unique constraint on checkout_id means a double click finds this row instead of creating a second order.
   5. The saga reserves each line at a warehouse that can meet the chosen date, with a 10-minute expiry. Each line is one transaction on one shard: a conditional decrement of available on the (SKU, warehouse) row and an insert of a soft reservation keyed by (order id, line). Here the shirt is reserved at SEA4 and the chargers at PDX9, the nearest with stock for each. Lines are independent, often on different shards, so if one fails the saga releases the others rather than relying on a cross-shard transaction.
   6. The saga asks the payment service to authorize the quoted total, keyed by the order id. Authorization holds the funds without taking them; capture waits for shipment. The order id is the idempotency key, so a saga that retries after a timeout gets the original authorization back rather than a second hold. A timeout is an unknown outcome, resolved by asking again with the same key, never treated as a decline.
   7. The saga commits the reservations, then marks the order placed and writes order.placed to the outbox in one transaction. Commit clears each reservation’s expiry, so it can no longer lapse. Committing before marking placed means an order is never placed without stock behind it. The order row and its event commit together, so the event exists if and only if the order does.
   8. The buyer sees the confirmation; the cart is cleared and the outbox relay publishes order.placed. Click to confirmation is about 1 to 2 s, most of it the authorization. Everything else (choosing the warehouses that really ship, emails, search and recommendation signals) hangs off the event and never delays the buyer.
2. Open a product page and add to cart. The main read path. One page needs a product document, a price, stock near the buyer, reviews and recommendations; the aggregator reads them in parallel from caches and views and drops whatever misses its budget.
   1. The buyer opens a product page; the CDN serves the page shell and the images. The shell (title, images, bullets, variant picker) is the same for every buyer, so it is cached at the edge for 10 minutes and purged by product id when the listing changes. Images have content-hashed URLs and are cached for a year. Price, stock and anything personal are deliberately not in it.
   2. The client asks for the dynamic part of the page: buy box, review summary and recommendations. One call per page view, carrying the selected SKU and the delivery ZIP. The aggregator owns a 250 ms server budget and decides what to wait for, so the client never orchestrates six services over a phone connection.
   3. The aggregator reads the product document from the cache, falling back to the catalogue store on a miss. The hottest 2 M products (~100 GB) take about 90 % of reads; a miss is one key lookup in the store, around 10 ms. Concurrent misses for one product wait on a single in-flight read, so a product going viral cannot stampede the store.
   4. In the same fan-out it reads the SKU’s price and its stock flags for the buyer’s region from the views. Both are complete views of every SKU (~45 GB) that the price and inventory services keep current with events, so they never miss to a system of record. The delivery date is computed here from the fastest warehouse with stock and a transit-time table. If a view read fails, the buy box says "See price in cart" or a coarse "In stock" instead of blocking the page.
   5. Reviews and recommendations are fetched with their own short deadlines; recommendations miss theirs and are dropped. Reviews get 60 ms and fall back to a cached summary; recommendations get 80 ms and fall back to a precomputed best-seller list for the category, then to nothing. The response goes out at the deadline with whatever is ready, so another team’s p99 never becomes the page’s p99.
   6. The buyer, not signed in, adds a size to the cart; it is written under a guest cart id from a cookie. The first add mints a random guest cart id in a long-lived cookie; the cart itself is server-side, so it survives the browser closing and can be merged at sign-in. No stock is reserved, and the line keeps the price seen only so the cart can later say the price changed.
3. Prime Day: a deal opens at 10:00. The scale-breaking case: ten times the orders, and one SKU that thousands of buyers want in the same second. The price flips everywhere on the clock, stock is split so no row serialises the sale, optional widgets are shed, and checkout is admitted at the rate payments can take.
   1. Hours before, capacity is raised and the deal SKUs are flagged hot, splitting their stock rows into sub-counters. Autoscaling reacts in minutes and this spike arrives in seconds, so the fleet is sized for about 1.5× the forecast peak beforehand and the caches are warmed with the deal products. Each hot (SKU, warehouse) row becomes 10 sub-counters holding a tenth of its units, so ~1 k reservations/s on the busiest row becomes ~100/s on each.
   2. The deal price was published ahead with a start time, so at 10:00:00 every view switches together. The view holds the current price and the next one with its start time, and switches on the clock, so the flip does not depend on thousands of events landing in the same second. The quote applies the same rule from the price service’s own store, so the page and checkout agree to the second.
   3. Page views surge; the aggregator sheds recommendations and other optional widgets first. The degrade level is a runtime flag: level 1 swaps live recommendations for precomputed lists, level 2 serves review summaries stale, level 3 shows a coarse delivery promise instead of a date. Price, stock and Add to cart are never shed, because they are the path to an order.
   4. Place order requests are admitted at the rate checkout and payments can take; the excess waits briefly. Checkout is sized for ~2.5 k orders/s and the payment service has agreed a quota above that; beyond it the gateway queues requests behind a "Placing your order" screen instead of failing them, because a buyer who sees an error clicks again. The queue is keyed by checkout id, so retries do not take a second place.
   5. Reservations for the deal SKU land on random sub-counters at the nearest warehouse with stock. Each attempt picks a random bucket and runs the same conditional decrement; an empty bucket moves on to the others, and an empty warehouse to the next nearest that still meets the promise. The invariant holds per bucket, and the total holds because the buckets were cut from the real count.
   6. The last units go; the stock flip is published and pages show the deal as sold out within a second or two. Only threshold crossings are published (in stock, low, out) per warehouse, so a sell-out is a handful of events, not one per unit. Buyers who loaded the page a second earlier fail at reserve with a specific message and a waitlist offer: the honest cost of a cached page.
   7. Abandoned and declined checkouts return their units, and the deal briefly reopens. Deal SKUs use a 5-minute reservation expiry instead of 10, because a held unit is one someone else is waiting for. Released units go back to the bucket they came from, and the warehouse flips back to in stock like any other change.
4. A declined card and a crashed worker. The failure path. Every step that succeeded is either completed or undone, driven by durable state, so a double click never makes two orders and a dead worker never strands stock or a hold on a card.
   1. The buyer double-clicks Place order; the second request finds the pending order under the same checkout id. The insert is guarded by a unique constraint on checkout_id, so exactly one wins. The loser returns the same order id and status, and the client polls that order instead of starting another.
   2. Both lines are reserved; then the payment service declines the card. A decline is definitive, unlike a timeout. The saga records payment_declined on the order before doing anything else, so what happens next is driven by durable state rather than by a process that might die.
   3. The buyer is asked for another card while the reservations stay held, and leaves instead. Keeping the reservations while the buyer picks another card avoids losing a scarce item to a typo. The saga sets a durable timer for shortly before the reservations would expire; a new card re-runs only the authorization, with a new key per attempt (o_8812:2).
   4. The timer fires; the saga releases each reservation and marks the order cancelled. Compensation runs in reverse order of what succeeded, and each release is idempotent on (order id, line), so releasing twice returns the units once. The order ends in exactly one terminal state with a reason, which is what the buyer and support both see.
   5. Another order: the worker running its saga dies right after the authorization succeeds. The saga’s state and step log live in the order store, so when the worker’s 30-second lease lapses another worker resumes from the last recorded step. It repeats the authorization with the same key and gets the original result back; nothing happens twice.
   6. The resumed saga commits the reservations and places the order; the buyer’s polling sees it confirmed. The buyer waited about 30 seconds longer behind a "Placing your order" screen: slow, not wrong. Had the saga been lost entirely, the soft reservations would expire after 10 minutes and the nightly reconciliation would void the orphaned authorization.
   7. A sweeper releases any soft reservation past its expiry that no saga committed. The sweeper is the backstop, not the mechanism: a healthy saga always commits or releases. Its release is conditional on the reservation still being soft, so it cannot race a commit that lands a millisecond earlier, and a rising sweep count is the alarm that sagas are dying.
5. After the order: warehouses, shipments, capture. The asynchronous path. Checkout reserved at good-enough warehouses; now a planner chooses where the order really ships from, may split it, and each shipment is captured as it leaves.
   1. The fulfilment planner consumes order.placed and loads the order’s lines and reservations. Planning is off the buyer’s path on purpose: a good plan weighs every warehouse with stock, carrier cutoffs and box sizes, which is far too slow for the Place order click. The consumer is idempotent on order id, so a redelivered event plans nothing twice.
   2. It chooses the cheapest plan that still meets the promised date: one warehouse with every line, or a split. Candidates are warehouses with stock that can make the promised date; the cost is shipping per box plus a penalty per extra shipment. If one warehouse holds every line, consolidate there; otherwise use the fewest shipments. The date promised at checkout is a constraint, not a preference.
   3. Where the plan differs from checkout’s reservation, it moves it: reserve at the new warehouse, then release the old. The shirt was reserved at SEA4 and the chargers at PDX9; PDX9 has both, so the shirt moves and the order ships in one box. Reserve-then-release means the unit is never unheld in between. If PDX9’s last shirt went in the meantime, the plan keeps the original reservation, which already met the promise.
   4. The shipment is released to its warehouse for picking and packing. From here the warehouse’s own systems do the physical work. A unit can still turn out to be damaged or missing, the residual oversell no reservation prevents; the planner then re-sources the line from another warehouse, backorders it against inbound stock with a new date, or cancels it, by the category’s policy.
   5. When the box leaves, on-hand stock is decremented and the reservations are consumed. Shipping is what turns a reservation into a real decrement of on hand. Until then the unit counts as reserved, so available = on hand − reserved stays right while the box sits on a dock.
   6. The planner reports the shipment; the order service records it and captures that shipment’s amount. Capture per shipment: a split order is charged in parts as each part leaves, and a cancelled line is never charged. Each capture is idempotent on the shipment id. An authorization that would expire before a late backorder ships is renewed by the payment service.
   7. The buyer checks the order and sees each shipment’s status and date. Status is per shipment, not per order, because a split order is genuinely in two states at once. The order store is sharded by customer id, so "my orders" is a single-shard query.

Deep dives

The theory behind it

• Shopping cart and checkout design: Designing e-commerce carts and checkout: cart storage for guests and signed-in users, merging carts, pricing and promotions, tax and shipping, inventory reservation, the checkout state machine, payment integration, order creation, idempotency and handling failures and abandonment.
• Inventory, reservations and flash sales: Never overselling: atomic decrements, reservations with expiry, holds versus commits, sharded inventory counters, queues and virtual waiting rooms for flash sales, bots, and keeping cached stock counts honest.
• Cache invalidation strategies: Keeping caches correct when data changes: TTLs, delete on write, write-through and write-behind, the race conditions that leave stale data, versioned keys, invalidation from change data capture, leases against stampedes, and multi-layer caches.

Related

• Design a URL Shortener
• Design a News Feed
• Design Ticketmaster
• Design Search Autocomplete
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit