🛒 Design E-Commerce Platform — System Design Interview Guide

Hard · Transactions & Inventory

Design an e-commerce platform like Amazon that handles product catalog, inventory management, shopping cart, checkout, and order fulfillment at massive scale.

Open the interactive E-Commerce Platform design on PrepGrind → Drag load balancers, caches, databases, and queues onto a canvas, run a live traffic simulation to watch latency and bottlenecks under load, and follow the full interview walkthrough below — free, in your browser.

Functional requirements

Browse and search product catalog with filters
View product details, images, reviews, and inventory status
Add items to shopping cart (persisted across sessions)
Checkout: place order, select shipping, confirm payment
Order tracking and history
Seller portal: list products, manage inventory, view orders

Non-functional requirements & scale

100M daily active users; 10M orders per day (~115 orders/sec)
Peak flash sale: 10× normal traffic (1M orders/sec for top items)
Product search results < 100ms
No overselling: inventory must be consistent under concurrent purchases
Payment success rate > 99.99%
Cart data must persist — loss is unacceptable

Capacity estimation

Normal: 115 orders/sec. Flash sale: ~1M/sec on hot items. Inventory decrement must be atomic to prevent overselling. Cart = session-like data (Redis). Orders = ACID transactions. Catalog = read-heavy (cached), inventory = write-heavy during sales.

Core entities

Product — productId, sellerId, name, description, price, categoryId, images[], status
Inventory — productId, warehouseId, quantity, reservedQty, updatedAt
Cart — cartId (=userId), items[{productId, qty, price}], updatedAt
Order — orderId, userId, items[], status, totalAmount, shippingAddr, paymentId, createdAt
Payment — paymentId, orderId, amount, status, gateway, idempotencyKey

API design

GET /api/v1/products?q=&category=&cursor= — Search products. Backed by Elasticsearch.
PUT /api/v1/cart/items — Add/update cart item. Body: { productId, qty }. Returns updated cart.
POST /api/v1/orders — Place order from cart. Atomically reserves inventory. Returns { orderId, paymentUrl }.
POST /api/v1/payments — Process payment. Idempotency key in header. Calls payment gateway.

High-level design

Browse: Elasticsearch for search, Redis cache for product details. Cart: Redis hash keyed by userId. Checkout: atomic inventory reservation (DB transaction / Redis DECR), then async order processing via Kafka.

Deep dives

🔒 Preventing Overselling

Naive: UPDATE inventory SET qty = qty - 1 WHERE qty > 0. Works but creates DB hotspot on flash sales. Better: Redis DECR for in-memory atomic counter (100K ops/sec per key). DB as source of truth, Redis as rate limiter. Pre-check Redis; if positive, proceed to DB transaction. Optimistic locking: include version in UPDATE WHERE clause.

🛍️ Flash Sale Architecture

Separate flash-sale service. Pre-allocate inventory tokens in Redis (SET token:productId count). Each purchase: atomically DECR. If result >= 0: proceed; else: reject immediately. Use rate limiter at gateway to shed load before reaching services. Queue overflow requests; process async with estimated wait time.

💳 Payment Idempotency

Network timeouts cause double-payment risk. Solution: client generates idempotencyKey (UUID). Payment service: INSERT INTO payments (idempotencyKey, ...) ON CONFLICT DO NOTHING; then check result. If payment already exists, return existing result. Store idempotency keys in Redis for 24h for fast lookup.

🔍 Product Search

Elasticsearch for full-text + filter search. Index: productId, name, description, categoryPath, price, rating, inStock. Faceted search: aggregations for filters. Cache frequent queries in Redis (TTL 5min). Write-through cache invalidation on product update. Use async indexing via Kafka — DB is source of truth.

Scaling considerations

Separate read-heavy catalog service (Elasticsearch + Redis) from write-heavy order service
Inventory reservation: 2-phase — reserve at checkout, confirm after payment
Order DB sharded by userId; order history reads from replicas
Kafka for order events: fulfillment, notifications, analytics are consumers
CDN for product images (S3 + CloudFront); image resizing with Lambda@Edge

What interviewers expect by level

Junior: Describe product catalog, cart, and checkout flow. Know why ACID transactions matter for inventory.
Mid: Redis for cart and caching, Elasticsearch for search, idempotent payments, basic inventory reservation.
Senior: Flash sale architecture, optimistic locking, Kafka-driven fulfillment pipeline, distributed inventory across warehouses.
Staff: Multi-region inventory synchronization, saga pattern for distributed checkout, cost model for Black Friday 10× peak.

Practice more system design case studies

PrepGrind runs entirely in your browser, free, no installation required. Loading the interactive playground…