E-commerce

Same startup, same engineer #4. Fifteenth Monday.

Your CTO drops by. "We want to build an e-commerce marketplace. Catalog, cart, checkout, inventory, orders. Support multiple sellers. Multi-region. Ship an MVP in 12 weeks."

She pauses. "For context — Shopify processed $11.5 BILLION in Black Friday/Cyber Monday 2024, peaking at $4.6 million per minute at 12:01 PM EST on Black Friday. That's about 700 orders per second sustained at peak. Amazon Prime Day 2024 needed 6,311 Aurora database instances handling 376 BILLION transactions across the event. Amazon deployed 250,000 Graviton chips across 5,800+ Amazon.com services. If you don't design for 100x burst on Day 1, you'll design a system that dies on Day 1 of your first Black Friday."

Here's the paradigm shift:

URL Shortener + Slack + Instagram + Twitter + Netflix + YouTube + WhatsApp + Dropbox + Uber + Payment + Cache + Kafka + Notification — each had ONE dominant workload dimension: read-heavy OR write-heavy OR real-time OR compute-heavy.

E-commerce is a bipolar workload: 99% of the year, browse RPS >> checkout RPS (100:1 read/write ratio). One day of the year (BFCM/Prime Day), checkout RPS goes 100x normal in the span of hours. Inventory correctness must not degrade. You can't be "eventually consistent" about whether 1000 units are still available — Nike's 2020 SNKRS launch was a case study in getting this wrong.

Shopify's answer was to build multi-region Vitess sharding + regional inventory pools + Kafka event fanout (Shopify Engineering blog). Amazon's answer was Aurora Global Database + custom AWS silicon (Graviton) + DynamoDB for cart state (AWS Prime Day 2024 blog). Both invested heavily in optimistic inventory locks with 15-min reservation TTL — because pessimistic locks would kill checkout throughput.

The real 2024 numbers

• Shopify BFCM 2024: $11.5B GMV (Shopify BFCM 2024 recap)
• Peak: $4.6M per minute at 12:01pm EST Black Friday = ~700 orders/sec sustained
• BFCM peak day: 284M requests/min at peak, 12 TB/min network, 7 TB/sec log ingestion
• 1.19 trillion edge requests, 10.5T DB queries, 1.17T DB writes during BFCM
• Amazon Prime Day 2024: 6,311 Aurora instances × 376B transactions × 3 PB stored × 444 PB EBS transfer (AWS Prime Day 2024)
• Amazon Prime Day: 250,000 Graviton chips across 5,800+ services
• Visa peak: 65,000 TPS — the card-network ceiling ecommerce sites hit at extreme scale
• Amazon Prime Day 2024 US sales: $14.2B (FitSmallBusiness stats)

Interview soundbite: "E-commerce at Shopify BFCM scale sustains 700 orders/sec + 284M requests/min. Amazon Prime Day needs 6,311 Aurora instances handling 376B transactions. The bottleneck is NEVER browse throughput — it's (a) inventory correctness during flash sales without pessimistic locks that would kill checkout, (b) 100x burst provisioning for one weekend a year, (c) provider failover if Stripe has an outage. If you don't name optimistic locks + 15-min reservation TTL + Vitess/Aurora Global + Kafka event fanout, you'll fail the L6 signal."

The whole journey at a glance

Every 10× in orders/day surfaces different bottlenecks — and BFCM peak is 100x normal:

text
    ═══════════ E-COMMERCE ARCHITECTURE ACROSS 4 SCALES ═══════════

    L4 (10K ord/day)   L5 (100K ord/day)  L6 (1M ord/day)          L7 (BFCM/Prime Day peak)
    Django + MySQL     Multi-AZ + ES      Regional inventory pools Aurora Global + Graviton
    12 weeks · $10K/mo 6 months · $100K/mo 18 months · $500K/mo    ongoing · $10M+/yr peak

    ┌────────┐         ┌────────┐         ┌── Global CDN ─────┐  ┌── Own edge + Aurora ─┐
    │  Web   │         │  Web   │         │  Cloudflare edge  │  │  Global · anycast   │
    │Mobile  │         │Mobile  │         │  + WAF + rate lim │  │  + Aurora Global DB │
    └───┬────┘         └───┬────┘         └─┬──┬──┬──┬─────────┘  └──┬──┬──┬──┬──────────┘
        │                  │                │  │  │  │              │  │  │  │
     ┌──▼───┐           ┌──▼──┐           ┌──▼──▼──▼──▼─────┐    ┌───▼──▼──▼──▼──────────┐
     │ ALB  │           │ ALB │           │  Regional ALB   │    │ Multi-region ALB       │
     │      │           │     │           │  + API gateway  │    │ + rate limiters        │
     └──┬───┘           └──┬──┘           │  + CDN warming  │    │ + auto-scaling ×100    │
        │                  │              └───┬──────┬─────┘    └──┬──┬──┬──┬──────────┘
     ┌──▼──────┐       ┌───▼─────────┐    ┌───▼──────▼───┐          │  │  │  │
     │ Django  │       │ Java Spring │    │  Catalog svc  │       ┌──▼──▼──▼──▼──────────┐
     │ + MySQL │       │ Boot        │    │  Cart svc    │       │Amazon.com scale:     │
     │ + Redis │       │ + MySQL     │    │  Checkout svc│       │5,800+ microservices  │
     │ + Elast │       │ + ES        │    │  Order svc   │       │DynamoDB for cart     │
     └──┬──────┘       │ + Redis     │    │  Inventory   │       │Aurora Global DB for  │
        │              │ + Kafka     │    │+ Optimistic  │       │  transactional data  │
        │              └───┬─────────┘    │  locks (15m  │       │Kafka for events      │
        │              ┌───▼──┐           │  reservation)│       │Graviton silicon      │
        │              │ES for│           └───┬───────────┘      └──┬──┬──┬──┬──────────┘
        │              │catalg│           ┌───▼──────────┐          │  │  │  │
        │              │search│           │Vitess sharded│       ┌──▼──▼──▼──▼──────────┐
        │              └───┬──┘           │+ Regional    │       │Multi-region Aurora   │
     ┌──▼───┐          ┌───▼─┐            │  inventory   │       │Global · <1s failover│
     │MySQL │          │MySQL│            │  pools       │       │DynamoDB Global tables│
     │(cat +│          │+ 2  │            │+ Kafka event │       │ES for search         │
     │ inv+ │          │repl │            │  fanout      │       │Kafka event fanout    │
     │ orders          │icas │            │+ CDN cache   │       │  for post-checkout   │
     │Multi-│          └─────┘            └──────────────┘       │  side effects        │
     │AZ)   │                                                    └──┬───────────────────┘
     └──────┘                                                       │
                                                                 ┌──▼──────────────────┐
                                                                 │Stripe primary +     │
                                                                 │Adyen failover       │
                                                                 │+ chargeback recon   │
                                                                 └─────────────────────┘

    ↑                  ↑                  ↑                       ↑
   Boring.           ES for search      Vitess sharding.          Aurora Global. Graviton.
   Django MVP.       + Kafka event      Regional inventory        BFCM/Prime Day 100x burst
   Stripe direct.    fanout for post-   pools. Optimistic         needs 6K+ Aurora instances,
                     checkout side FX.  locks 15-min TTL.         12 TB/min network peak.

   Chapter 5      Chapters 6+6.5      Chapter 7+7.5              Chapter 8
   walks          walks through       walks through Vitess       walks through BFCM/Prime
   through        Elasticsearch +     + regional inventory       Day peak: Aurora Global,
   L4 MVP         optimistic inv      pools + Saga checkout      Graviton, 100x burst,
                  locks + Kafka                                   provider failover

  Key insight: E-commerce is a BIPOLAR workload. 99% of the year, browse >> checkout.
  BFCM/Prime Day day: 100x normal for hours. Inventory correctness must not degrade.
  The industry answer: optimistic locks + 15-min reservation TTL + regional inventory
  pools + Vitess/Aurora Global sharding. Shopify does 700 orders/sec sustained at peak;
  Amazon needs 6,311 Aurora instances. If you say "pessimistic locks" you fail L6.

The same 4 tiers as clean architecture diagrams

L4 · 10K orders/day · Django + MySQL + ES · $10K/mo · 12 weeks:

L5 · 100K orders/day · Multi-AZ + Kafka + optimistic locks · $100K/mo · 6 months:

L6 · 1M orders/day · Vitess + regional inventory pools · $500K/mo · 18 months:

L7 · BFCM/Prime Day peak · Aurora Global + Graviton + 100x burst · $10M+/yr:

Why every 10× breaks the architecture

1. Optimistic locks + 15-min reservation TTL is the L5 signal. Pessimistic locks (SELECT FOR UPDATE) kill checkout throughput at 1000+ concurrent buyers. Optimistic locks (UPDATE inv SET qty = qty - 1 WHERE qty >= 1 AND version = ?) let checkout scale linearly. 15-min reservation TTL cleans up abandoned carts. Reference: Shopify inventory reservation blog.

1. Regional inventory pools are the L6 lever. Global inventory sync at 100ms latency means checkout waits for cross-region confirmation. Solution: pre-allocate inventory to regional pools, reconcile async. Small over-allocation window is acceptable; slow checkout is not. Reference: Amazon inventory allocation patterns.

1. BFCM/Prime Day capacity planning is a multi-week effort. Amazon Prime Day 2024 needed 6,311 Aurora instances at peak. Shopify pre-scaled 100x before BFCM. Chaos drills at 50x weekly for 4 weeks prior are the industry standard. Reference: AWS Prime Day 2024 blog.

The 3 senior insights before we start Chapter 1

1. E-commerce is bipolar: 99% browse, 1% flash-sale, 0.01% BFCM/Prime Day. Design for the peak from Day 1 or pay for it in migrations later. Every major platform (Shopify, Amazon, Alibaba, Walmart) has multi-week BFCM/Singles-Day capacity planning as a formal engineering process.

1. Inventory correctness beats throughput. Nike's 2020 SNKRS launch oversold thousands of pairs. Result: PR nightmare + refund liability + eroded customer trust. Every serious e-comm platform uses optimistic locks + reservation TTL + graceful backpressure (queue overflow buyers instead of overselling).

1. Multi-provider payment failover is table stakes. Stripe's 2020 outage cost customers $100M+. Amazon uses Adyen as backup. Shopify uses Adyen + Stripe + Braintree in different regions. Naming this signals L6+ awareness of production reality.

Chapter map for the journey ahead

• Chapter 1 — Requirements (catalog, cart, checkout, inventory, orders, sellers)
• Chapter 2 — Capacity estimation (BFCM 700 orders/sec, Prime Day 6,311 Aurora)
• Chapter 3 — API design (browse, cart, checkout, order, seller ops)
• Chapter 4 — Data model (products, inventory, orders, carts — with state machines)
• Chapter 4.5 — Inventory model deep-dive: optimistic vs pessimistic locks
• Chapter 5 — L4 MVP: Django + MySQL + Elasticsearch + Redis. Works up to 10K/day
• Chapter 6 — L5: Kafka event fanout + optimistic locks + reservation TTL
• Chapter 6.5 — The checkout Saga: cart → inventory → payment → order → fulfillment
• Chapter 7 — L6: Vitess sharding + regional inventory pools + provider failover
• Chapter 7.5 — Multi-provider payment: Stripe/Adyen/Braintree failover
• Chapter 8 — L7: Aurora Global + BFCM/Prime Day 100x provisioning + custom silicon
• Chapter 9 — Failure modes: flash sale oversell, provider outage, cart abandonment, fulfillment lag
• Chapter 10 — Trade-off matrix (Shopify vs Amazon vs Alibaba vs WooCommerce)
• Chapter 11 — Interview masterclass: 45-min mock, questions to ask
• Chapter 12 — Defense: the 20 hardest interview questions on e-commerce

Ready? Chapter 1 next: what did the CTO actually ask for?