Design an E-commerce Platform (High-Level Design)

🟠 High-Level Design · Case Study · Senior

"Design an e-commerce platform" (an Amazon or Flipkart) is the ultimate integration question. There's no single clever algorithm — instead you have to compose many services (catalog, search, cart, inventory, orders, payments) into a coherent whole and reason about the two things that really bite at scale: search and not overselling inventory. It's a great test of breadth and service decomposition. Let's design it.

Step 1 — Requirements

• Functional: browse & search a product catalog; view a product; add to cart; checkout (reserve stock, pay, place order); track orders; reviews.
• Non-functional: browse is hugely read-heavy and must be fast & always-on; checkout must be correct — never sell the same last item twice, never charge without an order.

Step 2 — Service decomposition

🟠 A microservices split maps naturally to the domains, each owning its data:

Step 3 — The browse path (read-heavy)

🟠 Product pages and listings get orders of magnitude more traffic than purchases, so optimise reads hard: serve product images via CDN, cache hot product data, and — crucially — don't power search with SQL LIKE. Use a dedicated search index (Elasticsearch) built for full-text, filters, and facets (brand, price, rating). The catalog DB is the source of truth; changes are streamed into the search index asynchronously (eventually consistent search is fine).

Step 4 — The checkout path (correctness-heavy)

🔴 This is where interviews go deep — the overselling problem: two shoppers buy the last unit at the same moment. You must not sell it twice.

• Reserve, then pay: at checkout, atomically reserve/decrement stock (a conditional update: UPDATE ... SET qty=qty-1 WHERE qty>0, or a short-lived reservation row) before charging. If the reserve fails, the item's sold out. This is the same reservation pattern as Ticketmaster seats.
• Idempotent payment: use an idempotency key so a retried checkout doesn't double-charge (see the payment system design).
• Tie it together with a Saga: reserve stock → charge → create order → notify, with compensating actions (release the reservation if payment fails; refund if order creation fails). You can't use one ACID transaction across services, so the saga gives you correctness with eventual consistency.
• Release expired reservations (cart abandoned) back to stock via a timeout job.

Step 5 — Scaling & consistency choices

🔴 Pick consistency per domain (CAP in practice): inventory & payments = strong consistency (money/stock must be exact); catalog, search, reviews, recommendations = eventual (a slightly stale product description is fine). Shard orders by user, catalog by product; put a message queue between services for async work (emails, analytics, search-index updates); keep order/inventory counts denormalised. Handle flash sales (a single hot item) with queued admission or per-item locking to serialise the contention.

The interview-ready walkthrough

"I'd decompose into catalog, search, cart, inventory, order, payment services, each owning its data. Browse is read-heavy — CDN for images, caching, and a dedicated search index (not SQL LIKE), kept eventually consistent from the catalog. Checkout is correctness-heavy — the key risk is overselling, which I solve by atomically reserving stock before charging, an idempotent payment, and a Saga with compensating actions across services. I'd make inventory and payments strongly consistent and everything else eventual, shard by user/product, and queue async work." That names the decomposition and the two hard parts — search and inventory correctness."

What to read next

• Design Ticketmaster — the reservation/overselling pattern in depth
• Design a Payment System · Saga transactions — the checkout backbone
• Microservices Architecture — the decomposition principles
• ← The complete System Design guide (hub)

← Design a leaderboard · Back to the hub →