System Design HLD Example: E-Commerce Platform (Amazon)

Scenario context

A large-scale e-commerce platform separates catalog, cart, inventory, orders, and payments into independent microservices. The core architectural challenge is Inventory Correctness during flash sales—solved with a two-phase reservation pattern: an atomic Redis DECR for high-speed "soft" reservation and an optimistic-lock SQL update for the final "hard" commitment.

Imagine it’s 12:00 PM on Prime Day. A "Lightn…

This walkthrough focuses on The Prime Day Pressure Cooker.

Before making a design choice, clarify:

• Imagine it’s 12:00 PM on Prime Day.
• A "Lightning Deal" for the latest iPhone goes live at 90% off.
• There are exactly 1,000 units available.

Concepts in play: caching, system-design-hld-architectures, consistency-replication, api-gateway

Stage 1 — E-Commerce Systems: Use Cases & Requirements

• Actors - Shopper / Buyer: Browses products, manages a cart, and places orders.
• • Merchant / Seller: Lists products, manages stock levels, and fulfills orders.
• • System Admin: Monitors platform health, manages global promotions, and handles fraud.
• Functional Requirements - Catalog Management: Search and browse millions of products with filters.

Observable outcome: Functional Requirements - Catalog Management: Search and browse millions of products with filters.

Stage 2 — Basics: Baseline Architecture

• An e-commerce system is essentially a Distributed State Machine .
• Every order moves through a series of transitions, and the system must ensure that data remains consistent across multiple specialized services.
• The baseline architecture separates concerns into: 1.
• The Read Path (Catalog & Search): Optimized for massive scale and eventual consistency.

Observable outcome: The Read Path (Catalog & Search): Optimized for massive scale and eventual consistency.

Stage 3 — Mechanics: The Two-Phase Reservation Logic

• The most critical mechanic in e-commerce is how we handle the "Check-and-Reserve" of inventory.
• We use a Hybrid Two-Phase Pattern : - Phase 1: Soft Reservation (Redis): We keep a high-speed counter in Redis.
• Every checkout attempt performs an atomic DECR .
• If the result is $\ge 0$, the user proceeds.

Observable outcome: If the result is $\ge 0$, the user proceeds.

Stage 4 — Estimations & Design Goals

• The Math of Amazon-Scale - Total Products: 100 Million SKUs.
• • Peak Orders: 10,000 orders per second.
• If we have 10k orders/sec, we have 500k product views/sec.
• • Storage Growth: 10k orders/sec 2KB per order = 1.7 GB of data per minute .

Observable outcome: - Storage Growth: 10k orders/sec 2KB per order = 1.7 GB of data per minute .

Stage 5 — High-Level Design: The Distributed Microservices Architecture

• The following architecture illustrates the separation of concerns between discovery, transaction, and fulfillment.
• The diagram above reveals the three-path separation that makes Amazon-scale e-commerce resilient.
• The Discovery Path uses Elasticsearch and Redis—both read-optimized—so that browsing the catalog never touches the transactional database.
• The Transaction Path contains all ACID operations.

graph TD
    User((User)) --> LB[Load Balancer]
    LB --> AG[API Gateway]

    subgraph Discovery_Discovery
        AG --> PCS[Product Service]
        PCS --> PDB[(Catalog DB: Postgres)]
        PCS --> RC[(Catalog Cache: Redis)]
        AG --> SES[Search Service]
        SES --> ES[(Elasticsearch)]
    end

    subgraph Transaction_Path
        AG --> CS[Cart Service]
        CS --> RCart[(Cart Cache: Redis)]
        AG --> OS[Order Service]
        OS --> IS[Inventory Service]
        IS --> RInv[(Inv Counter: Redis)]
        IS --> PInv[(Inv DB: Postgres)]
        OS --> PS[Payment Service]
    end

    subgraph Fulfillment_Async
        OS --> Kafka[Kafka]
        Kafka --> NS[Notification Service]
        Kafka --> AS[Analytics Service]
        Kafka --> WS[Warehouse Service]
    end

Observable outcome: The Transaction Path contains all ACID operations.

Stage 6 — Deep Dive: How the Two-Phase Reservation Prevents the Overselling Trap

• The Two-Phase Reservation pattern is the core innovation that separates a production e-commerce platform from a demo.
• Understanding its internals explains why the inventory system can sustain 50,000 simultaneous checkout attempts on a single SKU.
• Internals: Phase 1 (Soft Reserve) and Phase 2 (Hard Commit) State Machine Phase 1 is a single atomic decrement on a Redis counter for the SKU.
• Redis processes this as a single CPU instruction — truly atomic even under extreme concurrency.

Observable outcome: Redis processes this as a single CPU instruction — truly atomic even under extreme concurrency.

End-to-end outcome

After working through the stages, you should be able to explain:

• Lesson 1 — The cart is not the inventory.
• Never decrement real inventory when an item is added to cart.

Alternatives considered

Microservice Independence vs. Distributed Transaction Complexity

Critical Failure Mode — The Compensation Loop: If the payment gateway succeeds but the Postgres hard-commit fails (e.g., database timeout during high load), the Redis counter has already been decremented and the customer charged.

Failure and degraded modes

The source does not isolate a separate failure mode. Limits that matter for the scenario are called out in the stage decisions above.