System Design Interview: Design an E-Commerce Platform (Amazon / Shopify)

By /
⏱ 5 min read

System Design Interview: Design an E-Commerce Platform (Amazon / Shopify)

An e-commerce platform handles product discovery, inventory management, order processing, and payment — all while maintaining consistency under high concurrent load during sales events. This guide covers the architecture used by Amazon and Shopify, with emphasis on the inventory, ordering, and search systems that interviewers focus on.

Requirements

Functional: browse and search products (catalog), manage product inventory, add to cart, checkout with payment, track orders, handle returns and refunds, manage seller listings (marketplace model).

Non-functional: 100M active users, 1M orders/day, search results in <200ms, no overselling (inventory consistency), 99.99% checkout availability.

Core Services

1. Product Catalog Service

products(id, title, description, brand, category_id, seller_id, status)
product_variants(id, product_id, sku, size, color, price, images)
categories(id, parent_id, name, path)  -- tree structure

The product catalog is read-heavy and write-rarely. Cache product data in Redis (TTL 5 minutes) and Elasticsearch for search. When a product is updated, invalidate the Redis cache and re-index in Elasticsearch asynchronously via Kafka.

2. Inventory Service

Inventory is the hardest part — preventing overselling under concurrent purchases:

inventory(sku_id, warehouse_id, quantity_available, quantity_reserved)

-- Reserve inventory at checkout (atomic):
UPDATE inventory
SET quantity_reserved = quantity_reserved + :qty,
    quantity_available = quantity_available - :qty
WHERE sku_id = :sku AND warehouse_id = :wh
  AND quantity_available >= :qty;  -- only succeeds if stock available
-- Returns 0 rows updated = out of stock → fail checkout

-- Commit on order completion:
UPDATE inventory SET quantity_reserved = quantity_reserved - :qty
WHERE sku_id = :sku AND warehouse_id = :wh;

-- Release on checkout abandonment or cancellation:
UPDATE inventory SET quantity_reserved = quantity_reserved - :qty,
                     quantity_available = quantity_available + :qty
WHERE sku_id = :sku;

The single conditional UPDATE is atomic in PostgreSQL. No separate lock needed for the common case. Reservations expire after 30 minutes if checkout is not completed (background job releases them).

3. Search Service (Elasticsearch)

Product search must handle full-text, faceted filtering, and ranking:

GET /products/_search {
  "query": {
    "bool": {
      "must": [{"multi_match": {"query": "running shoes", "fields": ["title^3", "description", "brand^2"]}}],
      "filter": [
        {"term":  {"category": "footwear"}},
        {"range": {"price": {"gte": 50, "lte": 150}}},
        {"term":  {"in_stock": true}}
      ]
    }
  },
  "sort": [{"_score": "desc"}, {"sales_rank": "asc"}],
  "aggs": {
    "brands":    {"terms": {"field": "brand"}},
    "price_ranges": {"range": {"field": "price", "ranges": [...]}}
  }
}

Boost fields: title (3x), brand (2x), description (1x). Sort by relevance score then sales rank. Aggregations power the filter sidebar (brand, price, rating, color).

4. Cart Service

Shopping carts are ephemeral and session-bound. Store in Redis (Hash type, key: cart:{session_id}):

HSET cart:session_abc sku_123 2  # 2 units of sku_123
HSET cart:session_abc sku_456 1
EXPIRE cart:session_abc 86400    # expire after 24 hours of inactivity

# Cart contents:
HGETALL cart:session_abc → {sku_123: 2, sku_456: 1}

On checkout: transfer cart to a pending order record in PostgreSQL, then clear the Redis cart.

5. Order Service

Order state machine: PENDING → CONFIRMED → PROCESSING → SHIPPED → DELIVERED | CANCELLED | RETURNED

Each state transition is an event published to Kafka. Notification Service sends emails/SMS. Fulfillment Service picks and ships. Billing Service captures payment on CONFIRMED.

Flash Sale Architecture

Product launches (PS5 restock, limited sneakers) create massive concurrent demand:

  • Queue on high-demand items: virtual waiting room with Redis queue (same as Ticketmaster pattern)
  • Pre-warm inventory cache: cache inventory count in Redis, decrement on each purchase. Only hit PostgreSQL on cache miss or for final commit.
  • Dedicated flash sale service: isolate flash sale inventory checks from regular checkout to prevent cascading failures

Multi-Seller Marketplace

For marketplace (Amazon, Shopify Plus), multiple sellers list the same product:

  • Offer model: product_id + seller_id + price + quantity = an offer. Buy Box selects the best offer (price + shipping + seller rating).
  • Seller inventory: each seller manages their own inventory. Fulfillment can be seller-managed (FBM) or platform-managed (FBA).
  • Commission: platform takes 5-20% commission per sale, tracked in a separate financial ledger.

Interview Tips

  • Lead with the inventory reservation pattern — the conditional UPDATE preventing overselling is the key technical question
  • Explain the catalog/inventory separation: catalog is read-heavy + cacheable; inventory requires strong consistency
  • For search: Elasticsearch with multi_match boosting and aggregations is the standard answer
  • The cart in Redis (ephemeral) vs. order in PostgreSQL (persistent) is an important design distinction
  • For flash sales: describe the virtual waiting room rather than brute-force scaling

  • Coinbase Interview Guide
  • Uber Interview Guide
  • Airbnb Interview Guide
  • DoorDash Interview Guide
  • Stripe Interview Guide
  • Shopify Interview Guide

    • 🏢 Asked at: LinkedIn Interview Guide 2026: Social Graph Engineering, Feed Ranking, and Professional Network Scale

    🏢 Asked at: Databricks Interview Guide 2026: Spark Internals, Delta Lake, and Lakehouse Architecture

    Scroll to Top