Amazon#

Q: How does Amazon handle inventory consistency under heavy load?

Inventory writes go to a strongly consistent store per SKU per warehouse. Reservations are short held with idempotency keys, and the order pipeline confirms or releases the reservation atomically.

Q: How does Amazon scale catalog search?

The catalog is indexed in a heavily sharded search cluster with relevance models tuned for purchase intent. A separate ranking layer personalizes results using browse and purchase history.

Q: How does the cart service work in Amazon?

Carts are stored in a key value store keyed by user id with a JSON or protobuf blob. The service is intentionally available over consistent so reads never block during outages.

Q: How does Amazon prevent overselling during Prime Day?

Stock per SKU is reserved with row level locks at checkout. Pre-reservation queues with backoff smooth burst load, and unmatched reservations are reaped quickly so others can buy.

Q: How does the order pipeline split work after checkout?

The order service emits an event that fans out to payment, inventory, fulfillment, and notification. Sagas with compensating actions roll back partial work if any step fails.

Problem statement (interviewer prompt)

Design Amazon's core retail flow: browse a massive catalogue, add to cart, checkout, place an order, deduct inventory, charge payment, and fulfil from a warehouse. Handle 100k+ orders/min at peak (Prime Day) with strong consistency on payment + inventory.

flowchart LR
  U([User])
  CAT[Catalog]
  SRCH[Search]
  CART[Cart]
  ORD[Order]
  PAY[Payment]
  INV[Inventory]
  WHS[Warehouse / Fulfillment]
  U --> CAT
  U --> SRCH
  U --> CART --> ORD --> PAY
  ORD --> INV --> WHS

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class U client;
    class CAT,SRCH,CART,ORD,PAY,INV service;
    class WHS datastore;

flowchart TB
  subgraph Clients
    WEB([Web])
    MOB([Mobile])
  end

  subgraph Edge
    CDN
    GW[API Gateway]
  end

  subgraph Catalog[Catalog]
    CSVC[Catalog Service]
    CDB[(Catalog DB)]
    IMG[(Product images)]
    CACHE_C[Catalog cache]
  end

  subgraph Search
    SRCH[Search Service]
    IDX[(Inverted index)]
    RANK([Ranker - ML])
    AUTOC[Autocomplete]
  end

  subgraph Reco[Recommendations]
    SIM[Similar items]
    BB[Bought-also-bought]
    PRS[Personalized]
  end

  subgraph Cart[Cart & Checkout]
    CARTSVC[Cart Service]
    CARTDB[(Cart KV<br/>session)]
    CKT[Checkout]
    ADDR[Address book]
    TAX[Tax / Pricing]
    PROMO[Promo / coupon]
  end

  subgraph Order
    OSVC[Order Service]
    ODB[(Orders DB)]
    SAGA([Order Saga<br/>orchestrator])
    OUTB[[Outbox events]]
  end

  subgraph Inv[Inventory]
    INVSVC[Inventory Service]
    INVDB[(Inventory KV<br/>per SKU per warehouse)]
    RES[Soft reservation]
  end

  subgraph Pay[Payment]
    PAY[Payment Service]
    GTW((Stripe / Adyen / PayPal))
    REC([Reconciliation])
  end

  subgraph Ship[Fulfillment]
    WMS[Warehouse Mgmt]
    PICK[Pick / Pack / Ship]
    CARR[Carrier API<br/>UPS / FedEx]
    TRK[Tracking]
  end

  subgraph After[Returns / RMA]
    RMA[Returns service]
    REF[Refund]
  end

  subgraph Notif
    EMAIL[Email]
    PUSH[Push]
  end

  Clients --> CDN --> GW
  GW --> Catalog
  GW --> Search
  GW --> Reco
  GW --> Cart
  Cart --> Order
  Order --> Inv
  Order --> Pay
  Order --> Ship
  Order --> Notif
  Pay --> GTW
  Order --> SAGA --> OUTB
  OUTB --> Inv
  OUTB --> Ship
  After --> Order

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class WEB,MOB client;
    class GW edge;
    class CSVC,CACHE_C,SRCH,AUTOC,SIM,BB,PRS,CARTSVC,CKT,ADDR,TAX,PROMO,OSVC,INVSVC,RES,PAY,PICK,CARR,TRK,RMA,REF,EMAIL,PUSH service;
    class CDB,IMG,IDX,CARTDB,ODB,INVDB,WMS datastore;
    class OUTB queue;
    class RANK,SAGA,REC compute;
    class GTW external;

Order flow as a saga#

Create order (PENDING).
Reserve inventory (compensate: release).
Authorize payment (compensate: void).
Capture payment + confirm order.
Hand off to WMS for fulfillment.
On failure at any step → compensations in reverse.

Inventory consistency#

Per-SKU-per-warehouse counters with soft reservations.
Read replica may show stale stock; final check at order placement.
Optimistic concurrency on stock decrement.

Storage choices#

Catalog: read-mostly → SQL/NoSQL with heavy cache.
Orders: SQL with strong consistency (financial).
Inventory: KV with optimistic CAS.
Cart: KV/session (eventual OK, low staleness).

Glossary & fundamentals#

Concepts referenced in this design. Each row links to its canonical page; the tag column shows whether it is a high-level (HLD) or low-level (LLD) concept.

Tag	Concept	What it is	Page
`HLD`	CDN	edge caching for static assets	cdn
`HLD`	API gateway / BFF	single ingress, auth, rate limit, routing	api-gateway
`HLD`	CAP / PACELC	C vs A under partition; L vs C otherwise	cap-pacelc
`HLD`	Leader/follower replication	sync/semi-sync/async replication, failover	replication-leader-follower
`HLD`	Distributed transactions	2PC, TCC, sagas, outbox/inbox	distributed-transactions
`HLD`	Search internals	inverted index, BM25, embeddings, ANN	search-internals
`LLD`	Concurrency primitives	mutex, semaphore, RW lock, atomic, CAS	concurrency-primitives

Quick reference#

Functional#

Browse catalog, search, recommendations.
Cart, checkout, multiple addresses & payment methods.
Order placement → inventory hold → payment → fulfillment.
Returns, RMAs, refunds.
Reviews, ratings, Q&A.
Marketplace (3rd-party sellers), FBA.

Non-functional#

p99 product page < 300 ms.
99.99% checkout availability.
Read:Write 100:1 for catalog; 10:1 for cart.
Strong consistency for orders + payments; eventual OK for catalog and views.

Capacity (rough)#

200+ M items, 1B+ users, 100k+ orders/min peak (Prime Day).
Catalog reads: millions/s.
Catalog storage: TB; with images many PB.

Schema highlights#

products(id, title, price, attrs, seller_id, category)
inventory(sku, warehouse, on_hand, reserved)
carts(user_id, [items])
orders(id, user_id, items[], status, totals, payment_id)
payments(id, order_id, status, amount, provider_ref, idempotency_key)

Trade-offs#

Microservices (1000s) enable team autonomy but require strong contracts.
Saga over 2PC for order flow.
Multi-warehouse inventory for latency / cost; complicates allocation.
Read replicas for catalog, but check stock at commit.

Refs#

Amazon engineering talks (DynamoDB origin, SOA papers), Werner Vogels blog.
"Building Mission-Critical Financial Services Apps" re:Invent.
ByteByteGo "Design Amazon", Alex Xu Vol 2.

FAQ#

How does Amazon handle inventory consistency under heavy load?#