System Design 3: E-Commerce Platform Architecture Design (HLD / LLD)

Designing an e-commerce giant like Amazon or Flipkart requires balancing extreme scale, low-latency search capabilities, strict transactional consistency for payments and inventory, and robust concurrency controls to handle high-demand flash sales without overselling.

1. Why Do We Need This? (Problem Statement & Status Quo)

Modern e-commerce platforms must ingest massive global traffic, allow users to seamlessly browse millions of catalog items, maintain reliable shopping carts, execute secure financial transactions, and deliver lightning-fast search results.

In a technical interview, treating an e-commerce application as a monolithic block is an instant failure. Because different components have vastly different performance, consistency, and availability profiles, the system must be modularized into a decoupled microservices architecture.

2. Core Mental Model & Real-Life Analogy

Real-Life Analogy: Think of an e-commerce platform like a massive department store combined with a bustling postal hub:

• The Catalog & Search (The Store Directory & Shelves): Needs to be instantly accessible to everyone at all times (High Availability), even if a price tag is off by a fraction of a second.
• The Checkout & Inventory (The Cash Register & Vault): Must be strictly audited and accurate (High Consistency). If two customers try to buy the last remaining concert ticket or iPhone at the exact same millisecond, the vault ledger must ensure only one succeeds to prevent overselling.

3. Step 1: Requirements Gathering (Functional & Non-Functional)

Before drafting any architecture, define clear system boundaries with the interviewer.

A. Functional Requirements

1. Product Search & Discovery: Users must search and filter products by title, name, or keywords.
2. Product Details: Users can view detailed descriptions, images, pricing, specifications, and reviews.
3. Cart Management: Users can select quantities and add/update items in their shopping cart.
4. Checkout & Payment: Users can securely check out and process payments.
5. Order Tracking: Users can view and track the status of their placed orders.
6. Concurrent Flash Sales: The system must efficiently handle high-concurrency purchases of limited-stock items (e.g., flash sales) without race conditions.

B. Non-Functional Requirements & Scale

• Scale: Target 10 million Monthly Active Users (MAU) and 10 orders per second.
• Latency: Search responses must return in under 200 milliseconds.
• CAP Theorem Strategy:
  • Search Module: Prioritize Availability (AP) over absolute consistency so users can always browse.
  • Payment, Orders, & Inventory: Prioritize Consistency (CP) to prevent financial discrepancies and overselling.

4. Step 2: Core Entities Identification

Five primary data entities drive the core e-commerce domain:

1. User: Account credentials, profile, and delivery addresses.
2. Product: Item metadata, description, pricing, and category.
3. Cart: User-specific temporary collection of selected product items and quantities.
4. Order: Finalized transaction record linking customer, purchased items, and payment status.
5. Checkout: Transient orchestration entity managing the payment and inventory allocation pipeline.

5. Step 3: RESTful API Design

6. Step 4: High-Level Architecture (HLA)

7. Step 5: Low-Level Design (LLD) & Component Deep Dive

A. User Service & Authentication

• Database: MySQL relational database storing user profiles, hashed passwords, email IDs, and delivery addresses.
• Flow: Upon successful login, the API Gateway validates credentials and issues a JWT token, which is attached to downstream microservice requests.

B. Search Service & Product Catalog Optimization

Searching a massive relational database via full-table scans is prohibitively slow and fails the 200ms latency requirement.

• Catalog Storage: MongoDB (Document DB) stores flexible product metadata schemas because different product categories require varying attributes.
• Search Engine: Elasticsearch is decoupled from the primary database to handle lightning-fast text and keyword queries.
• Data Synchronization (CDC):
  Structure & Concept Flow

  Copy DiagramCopy

  Product DB (MongoDB)

  |

  v (Change Data Capture / Debezium)

  Kafka Stream Topic

  |

  v

  Elasticsearch Index

   
• Image Delivery: High-resolution images are stored in an AWS S3 bucket and fronted by a CDN (Content Delivery Network). The product database stores lightweight CDN URLs rather than raw binary blobs.

C. Cart Service

• Database: PostgreSQL storing user carts.
• Dynamic Pricing Guard: Cart prices are never statically cached inside the cart table. Whenever a user views their cart, the service dynamically queries the Product DB to ensure prices and availability reflect current catalog values.

D. Checkout, Payment, and Event-Driven Pipelines (Kafka)

The checkout workflow coordinates payment processing, inventory decrementing, order recording, and user notifications.

Naive vs. Resilient Event-Driven Approach

• Naive Approach (Synchronous Chaining): The payment service directly calls the inventory and order databases. If any step fails mid-chain, the system enters an inconsistent state.
• Resilient Approach (Kafka Event Broker):
  Structure & Concept Flow

  Copy DiagramCopy

  Checkout Service

  |

  v (Payment Confirmed)

  Payment Service updates Payment DB

  |

  v (Publishes Payment Success Event)

  Kafka Broker (Topic: payment-events)

  |

  +---> Order Consumer Service ----> Updates Order DB

  +---> Inventory Consumer Service -> Updates Inventory DB

  +---> Notification Service ------> Emails / SMS User

   

8. Step 6: Handling High-Concurrency Flash Sales (The Overselling Problem)

During flash sales (e.g., thousands of users attempting to buy the last available iPhone), standard database checks fail due to race conditions across multiple microservice replicas.

The Redis Distributed Lock Solution

To prevent race conditions and inventory overselling:

1. Inventory Check: Verify stock availability in the inventory database.
2. Distributed Lock Acquisition: Acquire an atomic lock in a Redis cluster keyed by the product_id with a strict Time-To-Live (TTL) of 30–60 seconds.
3. Execution or Rejection:
   • If the lock is acquired, proceed with checkout.
   • If another thread holds the lock, immediately reject the transaction and notify the user that stock is exhausted.

9. Step 7: Database Scaling & Caching Strategies

• Inventory Database Caching: The Inventory DB is the core backbone of the system under heavy read/write load. To protect it from single-point-of-failure collapse:
  • Place a Redis cache cluster in front of the Inventory PostgreSQL database.
  • Use a Write-Through Caching or CDC Invalidation Pipeline to keep cache entries synchronized with the database in near real-time.
• Product Quantity Synchronization: A asynchronous CDC cron pipeline continuously updates inventory stock counts back to the MongoDB product catalog documents so browsing users see accurate stock status.

Summary and Key Takeaways

• Requirement Boundaries: System design interviews require separating functional user journeys (search, cart, checkout) from non-functional constraints (latency, CAP theorem, scale).
• Architecture Style: A microservices pattern isolates domains (Search, Cart, Checkout, Inventory, Payments) to scale independently.
• Search Optimization: Never search transactional databases directly; leverage Elasticsearch synchronized via Change Data Capture (CDC) pipelines.
• Asynchronous Decoupling: Use Apache Kafka between payment confirmation and downstream order/inventory updates to guarantee eventual consistency and system resilience.
• Concurrency Control: Protect limited-stock flash sales from race conditions using Redis distributed locks with strict TTLs.
• Caching Architecture: Protect core inventory databases using Redis caching layers paired with robust cache-invalidation strategies.