Amazon

Assume 300M monthly active shoppers, one billion active SKUs, 2B product detail page views per day on average, 400M searches per day, 500M cart mutations per day, and a peak shopping event that reaches 80M orders in one day. Assume an average order has three line items and peak traffic is roughly ten times average for browse and eight to nine times average for order placement.

Assume each catalog document has about 8 KB of searchable and renderable metadata after normalization, not counting images and videos. Product media is stored in object storage and served through the CDN. Order records average 4 KB including line items and state history pointers, while inventory ledger records average 300 bytes.

• Product-page reads: 2B product views per day divided by 86,400 seconds is about 23,000 reads per second on average. A major sale can reach about ten times average, so plan for roughly 250,000 product detail reads per second globally.
• Search reads: 400M searches per day divided by 86,400 seconds is about 4,600 searches per second on average. During peak browsing windows, plan for 60,000 search requests per second because search traffic is bursty and users refine filters repeatedly.
• Catalog storage: one billion SKUs times 8 KB of normalized title, attributes, offer summary, category, and ranking fields is about 8 TB raw. The search index adds token postings, doc values, sort fields, facets, replicas, and segment overhead, so 25 to 40 TB is a more realistic operational footprint.
• Orders: 80M orders in a peak day divided by 86,400 seconds averages about 925 orders per second. Peak windows can be 8x to 9x average, so provision the order path for about 8,000 orders per second before retries.
• Inventory writes: three line items per order at 8,000 orders per second is 24,000 item-level reservation or decrement operations per second. Add releases, failed payment compensation, warehouse adjustments, restocks, and duplicate-safe ledger writes, and provision around 50,000 inventory writes per second.
• Order storage: 80M orders times 4 KB is about 320 GB raw for a peak day. With order item indexes, state history, payment attempts, replication, and audit retention, daily durable storage can be several times higher.
• Cache: if the top five percent of products drive half of product-page views, caching tens of millions of hot product summaries and rendered fragments can remove most reads from catalog databases. Product media should be almost entirely CDN-served.

• products.product_id and products.sku_id support product-page lookups. Secondary indexes on category, brand, and status help back-office workflows, but search traffic should go to the inverted index.
• The search index stores token postings for title, brand, description, and attributes, plus doc values or columnar structures for facets such as price, rating, brand, category, seller, and delivery promise.
• inventory_stock.sku_id, warehouse_id is the authoritative stock key. Conditional updates must check available units or version before reserving or decrementing.
• carts.cart_id is the primary lookup key. carts.user_id, updated_at supports active cart lookup and cleanup.
• orders.user_id, created_at supports customer order history. A unique constraint on orders.user_id, idempotency_key or checkout_session_id, idempotency_key prevents duplicate orders.
• payment_attempts.order_id and payment_attempts.provider_reference support reconciliation and duplicate-safe payment callbacks.

Products are referenced by cart items and order items, but cart and order records store snapshots of title, price, seller, and tax-relevant attributes so later catalog changes do not rewrite purchase history. Inventory rows belong to SKU and warehouse pairs, and orders create inventory ledger entries rather than directly trusting cart state.

The search index is a derived projection of products, offers, availability hints, ratings, and ranking signals. It is not the source of truth. Orders and payment attempts form a state machine where each transition is durable and event-emitting.

Use a document store or wide-column store for catalog documents keyed by product ID and SKU ID. Use OpenSearch, Elasticsearch, Solr, or a custom search service for inverted indexes and faceting. Use DynamoDB conditional update, FoundationDB transactions, Spanner, or a strongly consistent relational store for inventory reservations and order idempotency.

Cart data can live in DynamoDB, Cassandra, Redis with persistence, or another low-latency key-value store with TTL. Orders usually deserve a transactional store or event-sourced ledger because payments, refunds, audits, and support workflows need durable history.

A product catalog is not one table. It includes parent products, sellable SKUs, seller offers, category taxonomy, attributes, images, compliance data, ratings summaries, and suppression state. The source of truth should be versioned by product ID and SKU ID so edits can be audited and emitted as ordered catalog events.

Product pages need a denormalized read model. Rather than joining product, seller, media, rating, and offer tables on every page view, build a product document that contains the fields needed to render the page. Large images and rich media stay in object storage and CDN; the catalog document stores references, metadata, and cache invalidation versions.

Search ingestion consumes catalog events, normalizes text, expands synonyms, maps attributes to typed fields, and writes index segments. Because indexing is asynchronous, the system should expose catalog_version and index_version metrics, monitor lag, and make checkout independent from search freshness.

The search index maps terms such as headphone, wireless, and brand names to posting lists of matching product documents. Ranking can combine textual relevance, sales velocity, conversion rate, price competitiveness, freshness, personalization, and sponsored placements.

Filters are not implemented by scanning product rows. Category, brand, seller, rating, color, size, price range, shipping speed, and availability are stored as facet-friendly fields. Search engines represent these as doc values, bitsets, or columnar side structures so the query can intersect posting lists with filters efficiently.

Dynamic fields require care. Price and availability can change faster than title or description. Common approaches are short-lived overlays, partial index updates, or a two-phase result assembly where search returns product IDs and a ranking score, then the Product Page Service overlays current price and availability hints. Checkout still revalidates the final values.

The inventory service must prevent oversell when many buyers attempt to purchase the same SKU. Use a stock row or shard keyed by SKU and warehouse with on_hand, reserved, safety_stock, and version. A reservation request succeeds only if available units are at least the requested quantity at the moment of the conditional update.

The conditional operation can be a SQL transaction with row lock, a DynamoDB conditional update, a FoundationDB transaction, or another compare-and-swap primitive. The mutation must also write a ledger entry with request ID, order ID or checkout session ID, quantity, reason, previous version, and new version. This makes retries idempotent and makes reconciliation possible.

For extremely hot drops, a single SKU can become a bottleneck. Options include a short-lived purchase queue, splitting inventory into reservation buckets, preallocating stock per region, or using a token bucket where each token represents one purchasable unit. The tradeoff is fairness and complexity versus raw throughput.

A cart should be fast and forgiving. It stores intent, not guaranteed allocation. It can accept updates while prices, seller eligibility, delivery promises, and availability are changing in other systems. Use a cart version so two devices do not silently overwrite each other.

Checkout is the boundary where intent becomes a contract. It reloads the cart, resolves each SKU and seller, reprices items, applies promotions, calculates tax and shipping, and checks inventory. If any item changed materially, the system should return a clear conflict and require shopper confirmation.

Do not reserve inventory on every add-to-cart by default at Amazon scale. Cart abandonment is too high and it would artificially hide stock from real buyers. Reserve only during checkout with a short TTL, or for special cases such as limited flash sales.

Order placement receives retries from browsers, mobile clients, gateways, and payment providers. The client should send an idempotency key for the order request, and the server should scope it to the shopper or checkout session. A unique constraint maps that key to exactly one order outcome.

Payment calls need their own idempotency key with the external provider. The order service records a payment_attempt before or atomically with the provider call, stores provider references, and handles callbacks idempotently. Duplicate callbacks should advance the same payment attempt or be ignored if the state is already terminal.

The workflow is a saga, not a single distributed transaction across inventory, payment, and fulfillment. If payment fails after inventory reservation, release the reservation. If inventory fails after payment authorization, void or refund the authorization. Use durable state transitions and an outbox so recovery workers can resume incomplete steps.

Pricing has two personalities. Browse pricing must be fast, cacheable, and close to current, while checkout pricing must be authoritative and explainable. Keep price rules versioned, store the rule version used for an order, and snapshot final line-item prices, taxes, discounts, and currency on the order.

Promotions and coupons need conflict rules, eligibility checks, budget limits, and abuse prevention. These checks should be deterministic at checkout and must not depend on a stale product page cache.

Recommendations are best-effort. They can use offline models for similar products and near-real-time signals from views, searches, carts, and purchases. Recommendation failure should never block product pages or checkout; return popular items or omit the module.

Read-heavy product pages should be served from multiple cache layers: CDN for media and static fragments, edge or regional caches for product summaries, service caches for catalog documents, and search result caches for common queries. Use short TTLs for volatile fields and event-driven invalidation for suppressions, compliance changes, or major price updates.

Eventual consistency is the price of scale. Catalog updates flow to search, cache, recommendations, and seller dashboards asynchronously. Inventory updates flow to availability hints and search filters. Orders flow to fulfillment, customer notifications, recommendations, and analytics. Each projection must tolerate duplicates, out-of-order events, and replay.

The user contract is preserved by revalidation. Search may show an item that just sold out, and a product page may show a price that changed seconds ago, but checkout must consult authoritative inventory and pricing before confirmation. Explain this boundary clearly.

Alternative one is a simpler monolithic commerce application with a relational database and synchronous joins. It is easier to build for a small store but cannot serve Amazon-scale read traffic or peak checkout concurrency.

Alternative two is to reserve inventory when an item is added to cart. This improves availability confidence but wastes stock because cart abandonment is high and malicious users can hoard inventory.

Alternative three is to make search query the catalog database directly. That avoids indexing lag but makes filtering and ranking slow, expensive, and hard to scale across hundreds of millions of products.

Do not use this architecture for a small merchant with thousands of products and low order volume. A managed commerce platform or monolithic application is cheaper and simpler until the business needs large-scale search, event-driven fulfillment, independent service ownership, and high-concurrency inventory protection.