Design an E-Commerce Platform: The System Behind Every Online Store

Amazon Prime Day: $12.7 Billion in 48 Hours

On Prime Day 2023, Amazon processed $12.7 billion in sales across 48 hours - that's $73,000 per second at peak. The system handled 100,000+ orders per minute while maintaining accurate inventory across millions of products. The hardest problem isn't serving product pages (CDN handles that). It's ensuring you never sell more units than you have - the inventory consistency challenge that defines e-commerce architecture.

E-Commerce System Decomposition

E-Commerce Platform Architecture:

  [User] -> [CDN] -> Product pages, images (cached aggressively)
       |
       v
  [API Gateway] -> Rate limiting, auth, routing
       |
       +---> [Catalog Service]     Read-heavy, cached in Redis
       |     /products/:id         Eventual consistency OK
       |
       +---> [Search Service]      Elasticsearch cluster
       |     /search?q=...         Async index from catalog events
       |
       +---> [Cart Service]        Redis (fast, ephemeral)
       |     /cart                 No strong consistency needed
       |
       +---> [Inventory Service]   PostgreSQL (source of truth)
       |     /inventory/:sku       STRONG consistency required
       |
       +---> [Order Service]       PostgreSQL + event bus
       |     /orders               Saga pattern for multi-step
       |
       +---> [Payment Service]     Idempotent, PCI-compliant
             /payments             External gateway (Stripe)

  Consistency levels by operation:
  Browse catalog: eventual (stale price OK for 30 sec)
  View inventory: eventual ('97 left' vs '100' is fine)
  Checkout:       STRONG (must not oversell)

Solving the Inventory Problem

Flash Sale: 10,000 Users Want Last 100 Units

Approach 1: Atomic Database Decrement
  UPDATE inventory
  SET stock = stock - 1
  WHERE sku = 'IPHONE-15'
    AND stock > 0
  RETURNING stock;
  -- rows_affected = 1 -> reserved
  -- rows_affected = 0 -> out of stock
  -- Problem: DB becomes bottleneck at 10K TPS

Approach 2: Redis Pre-Reservation (Amazon's approach)
  -- At sale start, load inventory into Redis:
  SET inventory:IPHONE-15 100

  -- Each checkout attempt:
  new_count = DECR inventory:IPHONE-15
  if new_count >= 0:
      reserve_confirmed()  -- proceed to payment
  else:
      INCR inventory:IPHONE-15  -- undo the decrement
      out_of_stock()

  -- Redis DECR is atomic and handles 100K+ ops/sec
  -- Async sync Redis count back to PostgreSQL

Approach 3: Two-Phase Reservation
  Add to cart  -> soft reserve (TTL: 15 min)
  Pay          -> hard reserve (permanent)
  Abandon cart -> TTL expires, stock released
  -- Prevents cart-hoarding attacks

Interview Tip

E-commerce interviews test your ability to apply different consistency levels to different operations. Show this spectrum: CDN-cached catalog (eventual, stale for minutes is OK), inventory display on product page (eventual, approximate count is fine), inventory at checkout (strong, atomic decrement or Redis DECR to prevent overselling). The key insight: only the checkout path needs strong consistency - everything else can be eventually consistent, which is how you scale to millions of concurrent users.