Design an E-Commerce Store

The ask

An e-commerce store sells products to buyers through a website and an app. Buyers browse, search, compare prices, and read reviews before they buy.

Independent sellers list products on the store. The store itself runs the catalogue, the checkout, the orders, and the reviews.

The store must never confirm an order for stock it does not have. A confirmed order is a promise to deliver.

Product pages must stay fast at peak traffic. Most visitors only browse, and browsing pays for nothing if the pages crawl.

Estimate the scale

The catalogue holds 100,000,000 products. Product data changes slowly, while product views arrive constantly.

1,000,000,000 product views / 86,400 seconds = 11,574 views per second.

10,000,000 orders / 86,400 seconds = 116 orders per second.

1,000,000 reviews / 86,400 seconds = 12 reviews per second.

1,000,000,000 views / 10,000,000 orders = 100 views per order.

Order traffic peaks at about 3 times the average rate. The checkout path must survive the peak, not the average.

10,000,000 orders / 86,400 seconds x 3 = about 347 orders per second at peak.

Reads dominate the store by volume. Writes dominate the store by risk, because a wrong write loses money or trust.

API and data

Search products takes search words, filters, and a page number. It returns matching products with price and rating summaries.

Get product takes a product ID. It returns the name, price, stock state, seller, and rating summary.

Place order takes a cart, a delivery address, and an idempotency key. The key makes a retried checkout create one order, never two.

Write review takes a product ID, a star rating, and review text. The service checks the buyer's order history before it stores the review.

A product record holds the product ID, name, price, stock count, and seller ID. An order record holds the buyer, the items, the total, and the order state.

Order states are placed, paid, shipped, delivered, and returned. A review record holds the product, the buyer, the linked order, the stars, the text, and a trust state.

High-level design

A load balancer spreads requests across app servers. The app servers stay stateless, so any server can answer any request.

Product pages are served from a cache and a content delivery network. Popular products are read far more than they change.

A search index holds a searchable copy of the catalogue. Product changes reach the index through a queue, a few seconds behind the database.

Checkout runs on its own write path. Stock checks, payment, and the order write stay off the browsing path completely.

Reviews live in their own service with their own store. A review problem can then never slow down checkout.

Product pages and search

The cache holds the rendered facts of popular product pages. A price or stock change removes the stale entry at once.

The search index is sharded by product ID. One search checks the shards and merges the best matches.

Stock shown on a page can be a few seconds old. That small staleness is acceptable for browsing.

Checkout never trusts the page figure. Checkout checks the real stock count at the moment of the order.

Checkout and orders

Checkout reads the stock count for every item in the cart. It holds the stock while payment runs, and it releases the hold if payment fails.

The hold and the stock decrease happen in one database transaction. Two buyers can then never take the same last item.

Payment goes to the payment service as a named step with an amount and an order ID. The store records the payment result on the order.

A double click or a retried request carries the same idempotency key. The service returns the first order instead of creating a second one.

After payment, a queue carries the confirmation message and the seller alert. A slow message path never blocks the buyer at checkout.

Deep dive: fake and weaponised reviews

A fake review is a review written without a real purchase behind it. Sellers buy fake praise for their own products.

A weaponised review is a review used as a weapon against someone else. Paid attackers post one-star reviews on a rival seller's products.

Extortion is the third shape. A reviewer threatens a seller with bad reviews unless the seller pays or sends free goods.

Reviews carry real weight in the store. The rating summary steers search order and buyer choice, so a fake rating steals real sales.

A burst exposes coordinated abuse. One product that normally gets 20 reviews a day suddenly receives 2,000 reviews in one hour.

2,000 burst reviews / 20 normal reviews = 100 times the normal daily count, inside one hour.

Open reviews build trust because any buyer can speak. Closed reviews feel safe but say little, because only invited buyers can speak.

The design therefore keeps reviews open and makes abuse expensive. Every control below raises the cost of a fake review without silencing real buyers.

Keeping reviews honest

A verified purchase review is a review linked to a delivered order for that product. The link is checked against the order store at write time.

The headline rating counts verified purchase reviews only. Reviews without a purchase still appear, clearly marked as unverified, below the verified ones.

One buyer gets one counted review per product. Editing the review updates the single stored review instead of adding another.

A burst hold protects a product under attack. Reviews arriving far above the normal rate wait in a moderation queue, and the rating stops moving until the burst is checked.

The review record stores trust signals with the text. The signals are account age, the linked order, delivery confirmation, and earlier review history.

Sellers can never edit or delete a review. A seller can appeal with order evidence, and the moderation queue decides.

Removed reviews leave the rating at once. The rating summary is recomputed from the reviews that remain, so deleted abuse stops counting immediately.

When parts fail

A cache failure pushes page reads onto the database. The store sheds load by serving shorter pages rather than failing outright.

A search index backlog makes new products appear late in search. Product pages still work, because pages read the product store directly.

Checkout pauses when stock cannot be checked. Selling stock that might not exist costs more than a short checkout pause.

A moderation backlog delays reviews, never orders. Trust work queues behind money movement by design.

Evaluation and trade-offs

The store trades a little page staleness for a lot of read speed. Stock truth is enforced once, at checkout, where it matters.

Verified-only headline ratings trade review volume for trust. Fewer reviews count, and buyers can believe the ones that do.

Burst holds trade review speed for rating safety. A genuine launch day waits in moderation, and that delay is the price of stopping paid attacks.

The design fits the scale because reads ride caches while writes stay small and guarded. Orders run at 116 per second, and each one passes the full stock and payment checks.

Scale of the store