DEV Community

Rohit Kori
Rohit Kori

Posted on

Designing an E-Commerce System

#architecture #scalability #systemdesign

Imagine opening Amazon or Flipkart during a major sale.

You search for a product, open its page, add it to your cart, choose an address, pay for the order, and eventually receive the package.

From the customer's perspective, the experience is simple:

Search
  ↓
Product
  ↓
Cart
  ↓
Checkout
  ↓
Payment
  ↓
Order
  ↓
Delivery
Enter fullscreen mode Exit fullscreen mode

Behind the scenes, however, many independent systems are working together.

The platform has to search through hundreds of millions of products, serve millions of product-page requests, keep carts available across devices, maintain accurate inventory, process payments, create orders, communicate with warehouses, and survive huge traffic spikes during events such as Black Friday or Prime Day.

The most interesting part of the design is not the product catalog itself. The difficult problems appear when large traffic, concurrency, inventory, payment, and distributed services meet each other.

This article walks through the system from the beginning and gradually introduces those problems.

1. Understanding the Requirements

Let's start with the customer experience.

A customer should be able to browse the product catalog and search for products using text and filters.

For example:

"wireless headphones"
Enter fullscreen mode Exit fullscreen mode

The customer might then filter by:

Brand = Sony
Price = ₹5,000–₹30,000
Rating > 4
Category = Headphones
Enter fullscreen mode Exit fullscreen mode

After finding a product, the customer should be able to view its details, add it to a cart, and proceed to checkout.

During checkout, the system needs to:

Validate the cart
       ↓
Check the current price
       ↓
Check inventory
       ↓
Reserve inventory
       ↓
Calculate the final amount
       ↓
Authorize payment
       ↓
Create the order
Enter fullscreen mode Exit fullscreen mode

After the order is created, other systems take over:

Order
  ↓
Fulfillment
  ↓
Shipping
  ↓
Delivery
Enter fullscreen mode Exit fullscreen mode

The platform also needs to support sellers, inventory management, notifications, recommendations, reviews, and analytics.

For this design, the most important parts are:

  • Product catalog
  • Search
  • Cart
  • Inventory
  • Checkout
  • Payment
  • Order management
  • Fulfillment
  • Notifications

The internals of warehouse management, advanced fraud detection, and recommendation algorithms can be treated as separate systems.

2. The First Important Observation

Not every part of an e-commerce platform has the same consistency requirements.

Consider a product search.

A customer searches:

"iPhone"
Enter fullscreen mode Exit fullscreen mode

It is perfectly acceptable if a newly added product takes a few seconds to appear in search.

Now consider inventory.

Suppose only one phone remains:

Stock = 1
Enter fullscreen mode Exit fullscreen mode

Two customers attempt to buy it at nearly the same time.

The system must not sell two phones.

This gives us an important distinction:

Browsing / Search
        ↓
Very high traffic
Eventual consistency is often acceptable

Checkout / Inventory / Payment
        ↓
Correctness is critical
Strong consistency is required
Enter fullscreen mode Exit fullscreen mode

This distinction will influence almost every architectural decision we make.

3. How Much Traffic Are We Designing For?

Before choosing databases and services, we need some scale assumptions.

Suppose our platform has:

100M+ registered users
10M+ daily active users
100M–500M products
Millions of orders per day
Tens or hundreds of thousands of search requests per second
Enter fullscreen mode Exit fullscreen mode

The exact numbers aren't important. They are assumptions that help us reason about the architecture.

Suppose we process:

10M orders/day
Enter fullscreen mode Exit fullscreen mode

The average is only around:

10,000,000 / 86,400
≈ 116 orders/sec
Enter fullscreen mode Exit fullscreen mode

That number might look manageable.

But designing for 116 requests/sec would be a mistake.

Traffic is not evenly distributed.

During a large sale, the system might suddenly receive:

10K+ checkout attempts/sec
Enter fullscreen mode Exit fullscreen mode

and search traffic could be much higher.

So we design for peak traffic, not average traffic.

This immediately tells us that different workloads need different scaling strategies.

4. The High-Level Architecture

A useful first version of the architecture looks like this:

                         USERS
                           |
                           ▼
                    CDN / API Gateway
                           |
              ┌────────────┼────────────┐
              ↓            ↓            ↓
           Product       Search        Cart
           Service       Service       Service
              |            |            |
              ↓            ↓            ↓
          Product DB   Elasticsearch   Redis
              |
              ↓
             Kafka
              |
       ┌──────┼───────────────┐
       ↓      ↓               ↓
   Inventory  Order        Other Events
       |       |
       ↓       ↓
  Inventory   Order DB
     DB
       |
       ↓
    Checkout
       |
   ┌───┼────────────┐
   ↓   ↓            ↓
Inventory Pricing  Payment
                    |
                    ▼
             Payment Gateway
                    |
                    ▼
                  Order
                    |
                    ▼
                  Kafka
                    |
        ┌───────────┼───────────┐
        ↓           ↓           ↓
   Notification  Warehouse   Analytics
Enter fullscreen mode Exit fullscreen mode

This diagram looks complicated, but the reasoning is straightforward.

We separate the system according to the workload:

Product browsing → cache / CDN / search index

Search           → Elasticsearch

Cart             → Redis

Inventory        → transactional database

Orders           → transactional database

Events           → Kafka

Payment          → payment provider

Flash sales      → Redis + queues
Enter fullscreen mode Exit fullscreen mode

Let's understand why each piece exists.

5. Building the Product Catalog

The product catalog is the foundation of the platform.

A product might contain:

productId
name
description
brand
category
price
images
attributes
rating
Enter fullscreen mode Exit fullscreen mode

The difficult part is that different categories have different attributes.

A T-shirt might have:

size
color
material
fit
Enter fullscreen mode Exit fullscreen mode

A laptop might have:

CPU
RAM
storage
screen size
GPU
Enter fullscreen mode Exit fullscreen mode

A book might have:

ISBN
author
publisher
language
Enter fullscreen mode Exit fullscreen mode

Because the structure isn't identical for every product, a document-oriented database such as MongoDB or DynamoDB can be a reasonable choice for the catalog.

A simplified document could look like:

{
  "productId": "P123",
  "name": "Sony Headphones",
  "brand": "Sony",
  "category": "Electronics",
  "price": 34999,
  "attributes": {
    "color": "Black",
    "connectivity": "Bluetooth"
  }
}
Enter fullscreen mode Exit fullscreen mode

The catalog database is the source of truth for product information.

But we shouldn't use this database directly for every product search.

6. Why Search Needs Its Own System

Searching a large catalog is a different problem from storing products.

Suppose the customer searches:

wireless headphones
Enter fullscreen mode Exit fullscreen mode

and wants:

Brand = Sony
Price = ₹5,000–₹30,000
Rating >= 4
Availability = In stock
Enter fullscreen mode Exit fullscreen mode

A relational or document database can perform simple queries, but at very large scale we want a system specifically optimized for search.

This is where Elasticsearch comes in.

The architecture becomes:

Product Database
       |
       ↓
Product Changed Event
       |
       ↓
     Kafka
       |
       ↓
 Search Indexer
       |
       ↓
 Elasticsearch
Enter fullscreen mode Exit fullscreen mode

Elasticsearch can provide:

  • Full-text search
  • Filtering
  • Faceted navigation
  • Autocomplete
  • Fuzzy matching
  • Relevance ranking

The customer request then becomes:

User
 ↓
Search API
 ↓
Elasticsearch
 ↓
Search results
Enter fullscreen mode Exit fullscreen mode

This keeps heavy search traffic away from the transactional product database.

7. Why Search Can Be Eventually Consistent

Suppose a seller creates a new product.