Design Amazon

Problem Statement & Context

Amazon is a multi-tenant commerce operating system, not a storefront: catalog, search, personalization, inventory, cart, checkout, payments, shipping, and returns all run together at global scale, each with its own latency and correctness budget. It connects hundreds of millions of buyers to millions of sellers and warehouses.

The two journeys

• Buyer: browse/search → filter → product detail page (PDP) → add to cart → checkout → pay → track → deliver → return/review.
• Seller: list products + variants + inventory → update price/promos → receive orders → pick/pack/ship → handle returns.

The central tension is the spine of the design

The load-bearing idea is a tension between two opposite requirements: browsing must be fast and cheap (eventually-consistent reads served from caches and search indexes), while money and stock must be correct (strongly-consistent, idempotent writes). A stale recommendation is harmless; a double-charged card or an oversold flash-sale item is not. So the architecture splits into a read-optimized discovery plane and a correctness-critical commerce plane, and almost every later decision traces back to which side of that line a feature sits on.

Scale anchors (state aloud)

• 300M+ active customers, 100M+ SKUs
• 2B+ monthly visits → tens of millions of orders/day
• 5–10× traffic spikes during Prime Day / holidays

Read fan-out dominates the load, but the rare write must never be wrong — that asymmetry is what makes this a classic end-to-end design question rather than a caching exercise.