Design an E-Commerce Platform like Amazon

• products(product_id, seller_id, title, description, category_path, attributes_json, image_urls, status, updated_at)
• variants(product_id, sku, attributes_json) for size and color combinations.

Partition by product id. Product pages are read millions of times and updated rarely, so a read-through cache serves nearly all reads. Every change publishes an event to the bus for search and other consumers.

A document model fits products whose attributes vary widely by category (a laptop and a shirt share almost nothing). A relational schema would need either sparse columns or an entity-attribute-value table, both awkward at this scale.

• GET /search?q=&category=&filters=&sort=&cursor= returns products with facet counts.

The index is sharded by product id and replicated; replicas are added before sales events. Query results for popular searches are cached for a short time.

Stock in search results is a cached flag updated from inventory events, so a result can say "in stock" seconds after the last unit sold. Checkout re-checks stock authoritatively, which is cheaper than querying inventory for every search hit.

• GET /cart
• PUT /cart/items/:sku with { quantity }
• DELETE /cart/items/:sku

Each cart is an independent small document, so the store partitions perfectly. Writes are frequent but tiny.

The cart favors availability over consistency: if two devices update it concurrently, the store merges by item (keeping the latest quantity per item). Losing an "add to cart" costs a sale, while a duplicate item is easy for the customer to fix.

• stock(sku, warehouse_id, available, reserved, version)
• reservations(reservation_id, order_id, sku, warehouse_id, quantity, expires_at, status)

The reserve step is one conditional update (UPDATE stock SET reserved = reserved + q WHERE sku = ? AND available - reserved >= q), so most SKUs never contend. For flash sales on a single hot SKU, stock is split into several sub-counters across rows, and a request tries a random sub-counter first, spreading lock contention.

Reserving at checkout rather than at add-to-cart avoids locking stock in abandoned carts while still guaranteeing that a paid order has its units. Expiring reservations ensure crashed checkouts give stock back automatically.

• POST /orders with { cartId, addressId, paymentMethodId, idempotencyKey } returns { orderId, status }.
• GET /orders/:id returns status, items, and tracking.
• POST /orders/:id/cancel.

• orders(order_id, customer_id, status, total, currency, address_json, idempotency_key, created_at)
• order_lines(order_id, sku, quantity, unit_price, reservation_id, shipment_id)

During sales, checkout requests that exceed capacity are placed in a queue with a waiting page, protecting inventory and payment from overload. The idempotency key makes client retries safe.

A saga with compensating steps avoids a distributed transaction across inventory, payment, and orders, which would hold locks across services and fail whenever any participant is slow. The cost is temporary intermediate states, which the order status exposes as "processing".

Calls to the processor carry idempotency keys derived from the order id, so retries never double charge. Captures run asynchronously when items ship.

Authorizing at checkout and capturing at shipment matches what is charged to what is actually sent, which matters for partial shipments and cancellations. The ledger is append-only, so every refund is a new entry rather than an edit, giving a full audit trail.