E-Commerce Platform

Problem Statement & Requirements

Design a large-scale e-commerce platform that allows sellers to list products, buyers to browse/search/purchase them, and the platform to handle the entire order lifecycle from cart to delivery — similar to Amazon, Shopify, or eBay.

Functional Requirements

• Product Catalog — sellers create, update, and manage product listings with images, descriptions, variants (size/color), and pricing
• Search & Browse — full-text search, category navigation, filters (price, rating, brand), sorting (relevance, price, newest)
• Shopping Cart — add/remove items, persist across sessions, handle inventory changes (item goes out of stock while in cart)
• Checkout & Order — address selection, shipping method, payment, order placement (atomic: reserve inventory + charge + create order)
• Inventory Management — real-time stock tracking per SKU per warehouse; prevent overselling
• Order Management — order status tracking (placed → paid → shipped → delivered → returned)
• Reviews & Ratings — customers rate and review purchased products
• Recommendations — "Customers who bought X also bought Y", personalized homepage
• Seller Dashboard — order management, inventory, analytics, payouts
• Promotions & Coupons — percentage/fixed discounts, flash sales, buy-one-get-one

Non-Functional Requirements

• High availability — 99.99% (< 53 min downtime/year); checkout must never go down
• Low latency — product page load < 200 ms; search results < 100 ms; checkout < 2 seconds
• Massive scale — 500M products, 300M active buyers, 2M sellers
• Consistency for inventory — never oversell; stock count must be accurate
• Eventual consistency acceptable — for reviews, ratings, recommendations
• Handle traffic spikes — 10x normal during sales events (Prime Day, Black Friday)
• Global reach — serve users across multiple continents with low latency

Out of Scope

• Warehouse robotics / physical logistics
• Advertising auction system (sponsored products)
• Detailed payment processing internals (see Payment System design)
• Customer support / ticketing system

Scale Estimations

Traffic

Storage

Bandwidth

Hardware Estimate

This first layer defines the system boundary. The next chapters add application logic and data dependencies. After examining the request paths and tradeoffs, we will add operational safeguards and bring the complete architecture together.

API Design

Product Catalog

GET /api/v1/products/{product_id}

Response (200 OK):
{
  "product_id": "prod-abc123",
  "title": "Wireless Bluetooth Headphones",
  "description": "Active noise cancelling, 30hr battery...",
  "brand": "SoundMax",
  "category": ["Electronics", "Audio", "Headphones"],
  "seller_id": "seller-xyz",
  "base_price": 7999,                      // cents
  "currency": "usd",
  "variants": [
    {
      "sku": "SKU-BLK-001",
      "attributes": {"color": "Black"},
      "price": 7999,
      "inventory": {"in_stock": true, "quantity": 234}
    },
    {
      "sku": "SKU-WHT-002",
      "attributes": {"color": "White"},
      "price": 8499,
      "inventory": {"in_stock": true, "quantity": 12}
    }
  ],
  "images": [
    {"url": "https://cdn.example.com/prod-abc123/main.jpg", "position": 1},
    {"url": "https://cdn.example.com/prod-abc123/side.jpg", "position": 2}
  ],
  "rating": {"average": 4.3, "count": 1847},
  "shipping": {"free_shipping": true, "estimated_days": "2-4"},
  "created_at": "2025-06-15T10:00:00Z"
}

Search

GET /api/v1/search?q=wireless+headphones
    &category=Electronics
    &price_min=3000&price_max=10000
    &rating_min=4
    &sort=relevance
    &page=1&per_page=24

Response (200 OK):
{
  "query": "wireless headphones",
  "total_results": 4523,
  "page": 1,
  "results": [
    {
      "product_id": "prod-abc123",
      "title": "Wireless Bluetooth Headphones",
      "price": 7999,
      "rating": 4.3,
      "review_count": 1847,
      "image_url": "https://cdn.example.com/.../thumb.jpg",
      "is_prime": true,
      "relevance_score": 0.94
    },
    ...
  ],
  "facets": {
    "brand": [{"name": "SoundMax", "count": 120}, {"name": "BeatPro", "count": 89}],
    "price_range": [{"range": "0-5000", "count": 1200}, {"range": "5000-10000", "count": 890}],
    "rating": [{"stars": 4, "count": 3100}, {"stars": 3, "count": 1423}]
  },
  "did_you_mean": null
}

Cart

POST /api/v1/cart/items
{
  "sku": "SKU-BLK-001",
  "quantity": 2
}

GET /api/v1/cart
Response:
{
  "cart_id": "cart-user123",
  "items": [
    {
      "sku": "SKU-BLK-001",
      "product_id": "prod-abc123",
      "title": "Wireless Bluetooth Headphones (Black)",
      "quantity": 2,
      "unit_price": 7999,
      "subtotal": 15998,
      "in_stock": true,
      "reserved_until": null           // stock not reserved until checkout
    }
  ],
  "subtotal": 15998,
  "estimated_tax": 1440,
  "estimated_shipping": 0,
  "estimated_total": 17438
}

Checkout & Place Order

POST /api/v1/checkout
Idempotency-Key: checkout-ord-456

Request:
{
  "cart_id": "cart-user123",
  "shipping_address_id": "addr-home",
  "shipping_method": "standard",
  "payment_method_id": "pm_card_4242",
  "coupon_code": "SAVE10"
}

Response (201 Created):
{
  "order_id": "ord-789xyz",
  "status": "confirmed",
  "items": [...],
  "subtotal": 15998,
  "discount": -1600,                    // SAVE10 = 10%
  "tax": 1296,
  "shipping": 0,
  "total": 15694,
  "payment_intent_id": "pi_abc123",
  "estimated_delivery": "2026-04-07",
  "created_at": "2026-04-03T10:30:00Z"
}

Order Status

GET /api/v1/orders/{order_id}

Response:
{
  "order_id": "ord-789xyz",
  "status": "shipped",
  "tracking": {
    "carrier": "UPS",
    "tracking_number": "1Z999AA10123456784",
    "estimated_delivery": "2026-04-07",
    "current_location": "Distribution Center, Memphis TN"
  },
  "timeline": [
    {"status": "confirmed", "at": "2026-04-03T10:30:00Z"},
    {"status": "paid", "at": "2026-04-03T10:30:02Z"},
    {"status": "processing", "at": "2026-04-03T11:00:00Z"},
    {"status": "shipped", "at": "2026-04-04T08:15:00Z"}
  ]
}

Data Model

Product & Variants

Order

Cart (Redis)

Core Design Decisions

Decision 1: Checkout Flow — Preventing Overselling

This is THE hardest problem in e-commerce. Two users checkout the last item simultaneously.

Option A: Pessimistic Locking (SELECT FOR UPDATE)

Option B: Optimistic Locking (CAS with Version)

Option C: Redis Atomic Decrement (for Hot Items)

Recommendation: Hybrid

Normal products: Optimistic locking in PostgreSQL (Option B)
  → Sufficient for 99% of SKUs (low contention)
  → Simple, DB is source of truth

Hot items / flash sales: Redis atomic decrement (Option C)
  → Pre-load stock count before sale starts
  → DECRBY for reservations, sync to DB async
  → Fall back to DB if Redis unavailable

Decision 2: Search Architecture

Decision 3: Microservice Boundaries

Detailed Flow Diagrams

Checkout Flow (The Most Critical Path)

Checkout Failure Compensation (Saga Pattern)

Product Page Load Flow

Caching Strategy

Inventory Management Deep Dive

Multi-Warehouse Inventory

Inventory Reservation Lifecycle

Event-Driven Communication Between Services

Handling Edge Cases

Flash Sale Thundering Herd

Problem: 10M users hit "Buy" at 12:00:00 for 1,000 units of a hot item

Solution: Multi-layer defense

  Layer 1: Rate limiting at API gateway
    → Max 1 checkout request per user per 5 seconds
    → Eliminates bot rapid-fire

  Layer 2: Virtual queue
    → At 11:59, users enter a virtual queue (random position)
    → Release users in batches of 1,000 every second
    → Queue page shows estimated wait time
    → Prevents 10M simultaneous DB writes

  Layer 3: Redis atomic decrement for stock
    → Pre-load 1,000 into Redis: SET stock:SKU-HOT 1000
    → DECRBY stock:SKU-HOT 1 (atomic, 100K+ ops/sec)
    → First 1,000 proceed; rest see "sold out" instantly
    → No DB contention at all for the "sold out" path

  Layer 4: Async order creation
    → The 1,000 winners get reservation tokens
    → Have 10 minutes to complete checkout
    → Actual order processing happens async (not in the thundering herd)

Price Changed During Checkout

Problem: Buyer adds item at $79.99, price changes to $89.99 during checkout

Solution: Price snapshot at cart add + revalidation at checkout

  1. Cart stores price_at_add: $79.99
  2. At checkout, re-fetch current price: $89.99
  3. Compare: different!
  4. Options:
     a) HONOR cart price (Amazon approach — better UX)
        → Show buyer: "Price was $89.99, you're getting it for $79.99"
     b) UPDATE to current price
        → Show buyer: "Price changed to $89.99 since you added to cart"
        → Let buyer decide to proceed or remove

  Recommendation: Honor cart price for small increases (< 10%)
                  Alert buyer for large increases (> 10%)

Distributed Order Across Multiple Sellers

Abandoned Cart Recovery

Cart abandoned (user added items but didn't checkout)

  Trigger: Cart has items AND no checkout in 1 hour

  Recovery pipeline:
  T+1h:   Email "You left items in your cart!" (with product images)
  T+24h:  Push notification "Your cart is waiting"
  T+72h:  Email with 10% discount code "Complete your purchase"
  T+7d:   Final email "Items in your cart are going fast"
  T+30d:  Cart auto-expires (Redis TTL)

  Conversion rate from abandoned cart emails: ~5-10%
  At 500M carts/day, even 5% = 25M recovered orders

Tradeoffs & Design Decisions Summary

Reliability & Fault Tolerance

Single Points of Failure & Mitigations

Graceful Degradation

Tier 1 (non-critical service down — Reviews, Recommendations):
  → Product page still loads, just without reviews/recs section
  → "Reviews temporarily unavailable" placeholder
  → Zero impact on checkout flow

Tier 2 (Search down):
  → Category browsing still works (served from cache/DB)
  → Search bar shows "Search is temporarily unavailable"
  → Redirect to category pages and "popular products"
  → Checkout unaffected

Tier 3 (Cart Redis down):
  → Fall back to session-cookie cart (limited, smaller)
  → Or: serve from DB-backed cart (slower, 50ms vs 1ms)
  → Checkout still functional

Tier 4 (Inventory Service degraded):
  → Accept orders with delayed inventory check
  → Queue orders; process when service recovers
  → Risk: small chance of overselling (notify buyer if so)
  → Better than blocking all orders during outage

Tier 5 (Payment Service down):
  → Checkout blocked (can't charge without payment)
  → Show: "Checkout temporarily unavailable, please retry"
  → Cart preserved, reserved inventory held
  → This is the one service where we CANNOT degrade

High-Level Architecture

Component Breakdown (Service Map)

Full System Architecture (Production-Grade)

Run a flash sale for one product while the rest of the catalog receives ordinary traffic. Protect the hot inventory key without slowing every product page. Then cancel a paid order after stock has been reserved: describe the separate inventory, payment, and order transitions instead of treating cancellation as deleting a row.

Interview Tips

1. Start with the checkout flow — This is the core of the system and the hardest part. Draw the saga: validate cart → reserve inventory → charge payment → create order. Explain what happens when each step fails (compensating actions).

2. Inventory overselling is the #1 follow-up — Have three solutions ready: pessimistic locking (simple, slow), optimistic locking (better throughput), Redis atomic decrement (flash sales). Explain when each applies.

3. Separate read and write paths — Product views (58K RPS, eventual consistency) vs checkout (580 TPS, strong consistency) are fundamentally different. Show you understand this by designing different solutions for each.

4. Search is a separate system, not a database query — Don't say "SELECT ... LIKE '%headphones%'". Explain: CDC pipeline → Kafka → Elasticsearch → faceted search with relevance scoring. 1-5 second index lag is acceptable.

5. Cart in Redis, not SQL — Explain why: temporary data, high-churn, sub-ms access, TTL for abandoned cart cleanup. 300M entries fit in ~100 GB Redis. Mention the fallback to DB-backed cart if Redis fails.

6. Price and title snapshot in order — Product can change after order is placed. The order MUST record what the buyer actually purchased: price, title, image URL — all snapshotted. Never join back to live product table for historical orders.

7. Flash sale architecture — Virtual queue → rate-limited admission → Redis stock counter → async order processing. This shows you can handle 10x traffic spikes without designing the entire system for peak.

8. Multi-seller, multi-warehouse — One order can involve 3 sellers from 2 warehouses. Explain sub-orders / fulfillment groups: each seller fulfills independently with its own tracking number. Buyer sees unified view.

9. Event-driven for async work — OrderCreated → email, seller notification, analytics, recommendation update. Don't make these synchronous in the checkout path. Kafka event bus decouples services.

10. End with caching layers — CDN (images) → API gateway cache (product JSON, 60s) → Redis (product/session/cart) → L1 in-process cache (category tree). Mention what is NOT cached: inventory counts, order state, payment status.