Lesson 20 — Designing a Large-Scale E-Commerce Platform

1. The Reality of Planetary Commerce: Where All Architectural Patterns Collide

In previous lessons, we solved specialized architectural challenges:

Each of those problems existed within a single bounded domain. But on an enterprise e-commerce platform like Amazon, Flipkart, or Shopify, all these architectural requirements intersect concurrently:

• Massive Read Surge: Millions of shoppers browse catalogs, apply multi-attribute filters, compare prices, and read user reviews simultaneously.
• Extreme Financial Precision: Payment charging cannot afford a single discrepancy. Double charging or silent order drops destroy user trust and lead to regulatory penalties.
• High-Concurrency Inventory Contention (Flash Sales): A flash sale offers only 100 units of a heavily discounted gadget. Within 500 milliseconds, over 100,000 users click "Buy Now" concurrently!
• Asynchronous Fulfillment Workflows: Once payment succeeds, downstream warehouse picking, carrier scheduling, automated invoice generation, and customer SMS alerts must coordinate reliably.

“E-Commerce system design is the ultimate synthesis of high-throughput caching (AP tier) and strict transactional correctness (CP tier).”

2. Requirements & Back-of-the-Envelope Calculations

Let us scope our enterprise e-commerce platform:

Back-of-the-Envelope Capacity Estimation

3. High-Level Microservices Architecture & Domain Decomposition

While beginning with a monolith is common for early startups, an enterprise e-commerce platform must be partitioned according to Domain-Driven Design (DDD) bounded contexts. Each microservice manages its own private database to prevent coupling (Database-per-service pattern):

   [ Web / Mobile Clients ] ──► [ Global Anycast CDN (Cloudflare) ] (Static Assets & Edge Cache)
                                          │
                                          ▼
                            [ API Gateway / Envoy Proxy ] ──► [ Distributed Rate Limiter ]
                                          │
           ┌──────────────────────────────┼──────────────────────────────┐
           ▼                              ▼                              ▼
  [ Catalog Service ]            [ Cart Service ]              [ Order Service ]
   (Search & Details)             (Redis / KV Store)           (Saga Orchestrator)
           │                              │                              │
     Elasticsearch /                      │                              ▼
      PostgreSQL Cache                    │                    [ Inventory Service ]
                                          │                     (Atomic Stock Locks)
                                          │                              │
                                          ▼                              ▼
                              [ Payment Gateway Bridge ]       [ Fulfillment Service ]
                               (Stripe/bKash + Idempotency)     (Warehouse & Dispatch)
                                          │                              │
                                          └──────────────┬───────────────┘
                                                         ▼
                                       [ Apache Kafka Event Bus ]
                                                         │
                                  ┌──────────────────────┴──────────────────────┐
                                  ▼                                             ▼
                     [ Notification Service ]                     [ Analytics & ML Stream ]
                      (SMS, Push, In-App Alerts)                   (Recommendations / Fraud)

Core Microservice Responsibilities:

4. Deep Dive 1: Product Catalog & High-Speed Search

Because 99% of customer requests represent browse and search interactions, this layer must be engineered for extreme read throughput and millisecond response times.

Why Relational SQL Fails at Scale for Catalog Search

Consider a shopper searching for "red nkie runing shoe size 10". If executed against a relational database with SQL wildcards:

• Full Table Scan: The query WHERE title LIKE '%nkie%' completely bypasses B-Tree indexes. Every disk block containing 100M rows must be scanned.
• Zero Typo-Tolerance: The user misspelled "Nike" as "nkie". Relational SQL returns zero results, causing direct churn.
• High Latency with Multi-Faceted Joins: Simultaneously filtering Brand: Nike, Color: Red, Size: 10, Price: $50-$100, and Rating > 4 requires expensive normalized table joins that take seconds to execute.

5. Deep Dive 2: Shopping Cart Architecture & Price Snapshots

While appearing straightforward, cart management involves two critical architectural decisions:

Challenge 1: Guest Sessions vs Authenticated Carts

Many visitors add items before authenticating. Storing temporary carts in relational databases introduces unnecessary write pressure.

• Anonymous Guest Cart: A cryptographic UUID cookie (cart_session_id) maps to a Redis or DynamoDB key (e.g., cart:guest:uuid-1234) with an automatic 7-day TTL.
• Post-Login Cart Merging: When the user logs in, the Cart Service retrieves both the guest cart and the user's permanent cart (cart:user:u-99), combines quantities up to maximum limits, and deletes the temporary guest key.

Challenge 2: Dynamic Prices vs Authoritative Price Snapshots

Suppose a buyer places a $800 laptop in their cart on Monday. On Wednesday, the merchant raises the price to $850. When the user visits checkout on Friday, what happens?

6. Deep Dive 3: Flash Sales & Zero-Overselling Concurrency

The hallmark system design interview question: "We have 100 units of stock, and 10,000 concurrent buyers hit checkout at the exact same millisecond. How do you guarantee that you never sell 101 units?"

The Critical Flaw: Naive Check-Then-Act Race Conditions

-- Step 1: Read stock
SELECT stock FROM inventory WHERE product_id = 42;

-- Application code: if (stock > 0) { ... }

-- Step 2: Decrement stock
UPDATE inventory SET stock = stock - 1 WHERE product_id = 42;

If 100 application threads execute Step 1 simultaneously, all 100 threads see stock = 100. All 100 proceed to execute Step 2. If 1,000 users do this, hundreds of invalid orders will be confirmed for physical inventory that does not exist—a catastrophic overselling failure.

Solution 1: Atomic Database Update with Conditional Guard

UPDATE inventory 
SET available_stock = available_stock - 1,
    reserved_stock  = reserved_stock + 1
WHERE product_id = 42 AND available_stock >= 1;

Relational database engines enforce atomic row-level locks on the single updated record. The database driver returns Rows Affected = 1 (reservation success) or Rows Affected = 0 (stock exhausted). It is mathematically impossible to oversell with this guard clause.

Solution 2: Flash Sale Peak (Redis + Lua Script Token Dispenser)

Under 50,000 requests per second, forcing 50,000 threads to queue for a single database row lock causes connection pool starvation, transaction timeouts, and database crash. To absorb this surge, requests are intercepted in-memory with Redis Lua scripts:

-- flash_sale_reserve.lua (Executed atomically inside Redis single thread)
local key = KEYS[1]
local requested = tonumber(ARGV[1])
local stock = tonumber(redis.call('get', key) or 0)

if stock >= requested then
    redis.call('decrby', key, requested)
    return 1 -- Reservation success! Token granted.
else
    return 0 -- Out of stock! Instant rejection.
end

Because Redis executes Lua scripts sequentially and single-threadedly, it instantly admits exactly 100 successful reservations in sub-millisecond time, while gracefully returning HTTP 410 "Sold Out" responses to the remaining 49,900 requests. Only the 100 successful tokens are placed onto a Kafka queue for asynchronous order creation.

7. Deep Dive 4: Payment Resilience & Idempotency

Network partitions and timeouts are inevitable. A user clicks "Pay", their bank account is debited, but before the gateway response reaches their device, the mobile connection drops. The shopper clicks "Pay" again. Without proper protection, they will be billed twice.

Furthermore, payment gateways notify merchants asynchronously through Webhooks. Because webhooks may arrive out-of-order or duplicate due to network retries, the Payment Service must handle webhook events idempotently by checking payment IDs against database unique constraints.

8. Deep Dive 5: Distributed Transactions & The Saga Pattern

In a microservices architecture, completing a single purchase spans multiple autonomous domains:

What occurs if the payment gateway declines the card due to insufficient funds? Does the reserved inventory remain trapped forever?

Why Two-Phase Commit (2PC) Fails in Production

Traditional distributed 2PC protocols hold database locks across network boundaries until all nodes vote. If any network node slows down, the entire transaction cascade freezes, exhausting database connection pools and creating a single point of failure.

The Saga Pattern & Compensating Workflows

Under the Saga pattern, each microservice executes a local ACID transaction and emits a domain event. If any forward step fails, the Saga Orchestrator dispatches Compensating Transactions in reverse order to roll back prior effects cleanly:

9. Hands-On Architecture Lab (Interactive Workbench)

Explore the distributed e-commerce architecture simulator below across three interactive scenarios:

10. Concept Check Quiz

Validate your architectural reasoning with these real-world enterprise scenarios:

11. Architecture Summary & Upcoming Grand Finale

In this lesson, we synthesized every foundational and real-world system design principle into an end-to-end enterprise architecture:

• Read/Write Segregation (CQRS): Inverted-index Elasticsearch search clusters paired with ACID relational order repositories.
• High-Concurrency Flash Sales: Atomic guard clauses and in-memory Redis Lua token gates ensuring zero overselling.
• Distributed Sagas: Resilient state machine orchestration with compensating rollbacks for payment decline.
• Payment Idempotency: Tokenized gateway integrations preventing double charges and securing asynchronous webhook reconciliation.