Design the inventory and checkout backbone for a large online store (think a popular marketplace during a flash sale). The system must let many shoppers browse a catalog, add items to carts, and pay — while never selling more units of an item than physically exist, even under a thundering herd on a handful of hot SKUs.

Operating context. The catalog holds ~50M SKUs across ~2M sellers. Catalog reads dominate: ~250k product-page and search reads/sec at steady state, spiking to ~1M reads/sec when a promoted drop goes live. Cart and checkout writes are far rarer — ~8k add-to-cart/sec and ~1.5k order-placements/sec — but during a flash sale, tens of thousands of shoppers converge on the SAME few hundred SKUs within seconds. Available stock per SKU ranges from single digits (limited drops) to millions (staples). Payment is delegated to an external processor whose confirmation is asynchronous and can arrive seconds later, or never.

Out of scope. Search relevance ranking, recommendations, pricing/promotions engines, fraud/risk scoring, warehouse/fulfillment logistics, returns and refunds, and the seller-facing catalog-ingestion pipeline. Assume separate teams own those; you may treat the payment processor as a black box with a webhook.

What to produce. A high-level architecture covering: the request paths (browse catalog, add to cart, place order, payment callback); the components and how they talk; the data model and how stock counts are partitioned. Then design the reservation-vs-decrement scheme that prevents oversell on hot SKUs, the cart and order state machine (including how a reservation is held, expires, or is released), the integration with the async payment processor (idempotency, timeouts, and the confirm/cancel outcomes), and where you accept eventual consistency for displayed stock versus where you demand a strong count. Sketch the major components and the flow between them; we probe specifics at checkpoints.