Design Amazon: System Design Interview Guide
Amazon.com processes 1.6 million orders per day at peak with a catalog of 350 million products, inventory across 175 fulfillment centers, and Prime delivery guarantees in 2 days or less.
Designing Amazon means designing an e-commerce stack from catalog and search through cart, checkout, inventory, payment, and fulfillment routing. It is one of the broadest system design problems because every step is a real subsystem with its own constraints. The hardest piece is keeping inventory consistent across 175 warehouses while serving sub-second search.
Asked at: Commonly asked at Amazon, Meta, Google, Walmart, Shopify, Flipkart, and any e-commerce or marketplace company. The Amazon variant is often more inventory-heavy than the Shopify variant.
Why this question is asked
Design Amazon spans more subsystems than any other interview problem. Interviewers use it to test whether you can decompose a giant problem into independent services, pick the right database per service, and handle a transactional pipeline (order to fulfillment) without losing inventory or charging twice.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Browse and search a catalog of 350M+ products
- Add to cart, update quantities, remove items
- Checkout with multiple payment methods and addresses
- Real-time inventory check before order confirmation
- Order placement triggers fulfillment center selection and routing
- Order tracking from placement to delivery
- Reviews, ratings, and Q&A
Non-functional requirements
- Search latency under 200 ms at the 99th percentile
- Product page load under 500 ms
- Strong consistency on inventory and orders
- 99.99% availability for checkout
- Scale to 1.6M orders per day with 30x peak factor on Prime Day
- Eventual consistency acceptable for reviews and counters
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Active customers
300M
Public reporting. Includes Prime and non-Prime.
Orders per day (peak)
1.6M
Average is ~1M, peak around Prime Day is 30x. Sized for the peak.
Products in catalog
350M
Public reporting. Includes third-party seller inventory. Sizes the search and catalog stores.
Search queries per second (peak)
200K
Browse traffic is much higher than buy traffic. Search peaks during Prime Day and holiday shopping.
Inventory writes per second (peak)
5K
Every order is multiple inventory decrements (one per line item). Plus restocks from suppliers.
High-level architecture
Customer-facing services: Catalog Service serves product detail pages from a denormalized read store; Search Service runs on a custom inverted-index system (A9 internally) consuming a Kafka feed of catalog updates; Cart Service stores carts in a sharded KV store (DynamoDB) keyed by customer_id; Checkout Service orchestrates the order placement saga across Pricing, Tax, Inventory, Payment, and Order services. Order placement: when checkout confirms, the Order Service writes a pending order, reserves inventory in the Inventory Service (transactional decrement against the relevant SKU and fulfillment center), captures payment via the Payment Service (idempotent), and commits the order. The fulfillment center is selected by the Fulfillment Routing Service based on inventory availability and geographic proximity. Post-order: events go to Kafka and feed downstream services (notifications, ML training, analytics).
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Catalog Service
Serves product detail pages. Backed by a denormalized read store (DynamoDB) with a separate write store for catalog updates. Heavy use of caching because catalogs change slowly.
Search Service
Custom inverted index (Amazon's A9 internally). Consumes a Kafka feed of catalog updates. Indexes title, description, brand, attributes, and reviews. Ranks by relevance, popularity, and personalization.
Cart Service
Stores per-customer cart in DynamoDB keyed by customer_id. Carts persist for guest users via cookies and merge on login. Eventually consistent reads are fine.
Inventory Service
Owns SKU and fulfillment-center inventory counts. Decrement on order reservation is a strong-consistency operation. Replenishment events update counts from supplier ingestion.
Order Service
Owns the order lifecycle. Writes to a sharded SQL store (relational because orders have complex state transitions). Emits OrderCreated, OrderPaid, OrderShipped events.
Payment Service
Captures payment from saved methods. Idempotent on order_id. Integrates with internal Amazon Pay, external card networks, and gift cards.
Fulfillment Routing Service
Selects which fulfillment center ships each line item. Optimizes for proximity (delivery speed), inventory availability, and operational cost.
Recommendation Service
Personalized product recommendations on the home page and product detail pages. Trained offline on order history. Uses a two-stage candidate-generation plus ranking pattern.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
productsproduct_id (PK)titlebrandcategory_pathattributes JSONimage_urls[]asinSharded by product_id hash. Denormalized for read performance. Updated by a separate catalog ingestion pipeline.
inventorysku (PK partition)fulfillment_center_id (clustering)available_countreserved_countlast_updatedSharded by sku. Strong consistency on decrement. Restocks are append-only events into a separate inventory_events table.
cartscustomer_id (PK)items[]: { product_id, quantity, price_at_add }updated_atDynamoDB. One row per customer. Price at add is captured so a price change does not surprise the customer at checkout.
ordersorder_id (PK)customer_idstatusline_items[]total_amount_centscurrencycreated_atSharded by customer_id. State transitions are append-only via order_events. The status column is a denormalized projection of the latest event.
shipmentsshipment_id (PK)order_id (FK)fulfillment_center_idcarriertracking_numberstatusAn order can have multiple shipments (split across fulfillment centers). Each shipment is tracked independently.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
The order placement saga
Order placement spans multiple services (Inventory, Payment, Order, Fulfillment) and must be all-or-nothing from the customer's perspective. A distributed transaction across these services would be slow and brittle. The standard pattern is the saga: a sequence of local transactions, each with a compensating action. Step 1: Inventory Service reserves inventory (decrement available, increment reserved). Step 2: Payment Service captures payment (idempotent by order_id). Step 3: Order Service marks the order as paid. If any step fails, compensating actions run: release the inventory reservation, refund the payment, mark the order failed. An orchestrator (Step Functions or a custom workflow engine) drives the saga and handles retries. The customer sees a single Order Placed confirmation only after the saga commits.
Inventory consistency across 175 fulfillment centers
Inventory is partitioned by (sku, fulfillment_center). A reservation must atomically decrement the count for a specific FC. The naive approach (single global counter per SKU) creates a hot row at scale. Instead, each FC owns its own row, and the Fulfillment Routing Service picks which FC to decrement. For SKUs with low total inventory (the long tail), a global Bloom filter or a cached aggregate avoids fanning queries to every FC. For SKUs with high inventory, the routing service can pick the nearest FC with stock. Restocks (a supplier delivers 1000 units to FC-DTW1) are append-only events that update the count.
Search at 200K QPS over 350M products
Search runs on a custom inverted index (A9). Catalog updates flow through a Kafka topic; an indexer consumes the topic and updates the index in near real time (seconds, not minutes). The index is sharded by product_id; a query fans out to all shards, each returns its top N matches, and a coordinator merges and re-ranks. Ranking combines text relevance (BM25-like), popularity (clicks and conversions), personalization (your past purchases), and business signals (Prime-eligible products boosted). The full ranking model runs only on the top few hundred candidates from each shard, not all matches.
Catalog reads at huge scale with denormalization
Product detail pages are the most-read pages in the system. Joining product, reviews, ratings, related products, and Prime eligibility at read time would be slow. Instead, catalog data is denormalized into a read-optimized store: each product row contains the title, description, image URLs, latest review snippets, average rating, and Prime flag. Updates to any of these (a new review, a stock change) trigger an async update of the denormalized row. The read path is a single key lookup. The write path is more complex but writes are rare relative to reads.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
Saga vs distributed transaction for order placement
Distributed transactions are slow, brittle, and lock-prone. Sagas with compensating actions are eventually consistent but recover cleanly from failures. Sagas win in any system that spans multiple services.
Per-FC inventory rows vs global counter
Global counter is a hot row at scale. Per-FC rows distribute writes but require the routing service to pick an FC. Per-FC wins because Amazon needs to know which FC has stock to make fulfillment decisions anyway.
DynamoDB vs SQL for carts
Carts are simple per-customer documents. DynamoDB scales horizontally with no manual sharding. SQL would require sharding by customer_id. DynamoDB wins for this workload.
Sharded SQL vs DynamoDB for orders
Orders have complex state, joins (line items), and reporting needs. Sharded SQL (Aurora or MySQL) gives you these. DynamoDB would force denormalization that hurts reporting.
Real-time search indexing vs batch
Batch (re-index nightly) misses price changes and new arrivals. Real-time (Kafka feed, seconds latency) keeps the index fresh at the cost of higher indexer load. Real-time wins for e-commerce.
How Amazon actually does it
Amazon's e-commerce stack is the famous example of microservices at scale: ~10,000 services as of the most recent public statements. DynamoDB was invented at Amazon to handle the cart and checkout workload. The Order Service is built on a homegrown saga orchestrator. Search runs on A9, a custom inverted-index service. Fulfillment uses a custom routing optimization service. Recommendations use a combination of collaborative filtering and deep learning. Prime Day traffic is handled by aggressive pre-warming, capacity reservation, and chaos engineering exercises in the months before.
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.