Design E-Commerce Platform

You are building the shopping side of a general marketplace: the part a buyer touches between typing "running shoes" into a search box and getting an email that says the parcel is on its way. Think of a store with 300 million listed SKUs, tens of millions of shoppers a day, and a calendar that includes a few sale days where traffic jumps by an order of magnitude before lunch.

The tension is simple to state. Almost every request is someone looking, and looking can tolerate data that is a few seconds old. A tiny fraction of requests are someone paying, and paying cannot tolerate any ambiguity at all: the unit they bought must exist, must be theirs alone, and the money must move exactly once. A good design admits that these are two different systems sharing a catalogue, and builds each one for its own job.

Pick round assumptions and say them out loud: 30 million daily active shoppers, about 18 browse requests each (searches, category pages, product pages), 1.2 million orders a day on an ordinary day, and a catalogue of 300 million SKUs. Sale days multiply traffic by about twenty for the first few hours.

Draw a line down the middle of the diagram. To the left of checkout is the browse plane: search, category pages, product pages and the cart. Everything there is a read or a cheap, forgiving write, and it is built from caches, a search index and stateless services that scale by adding pods. To the right is the buy plane: the checkout orchestrator, inventory, payments and orders. It handles a few hundred requests a second on a normal day and is built from transactional stores that are slower to scale but never lie.

The two planes talk through events, not shared tables. When stock changes or an order is placed, the orders database writes the change and an outbox row in one transaction. A change-data-capture connector streams those rows into Kafka, and consumers update the search index's in-stock flag, invalidate cached product pages, tell fulfilment to pick and pack, and trigger emails. If any consumer is down, events wait in Kafka and no buyer notices.

Never read stock into the application, compare, and write back. Push the comparison into the write itself, so the database's row lock serialises competing buyers for you:

Both statements run in one transaction on the SKU's shard. The update either moves units from available to held or touches nothing, and the hold row records who owns those units and until when. This is correct with no explicit locks, no SELECT ... FOR UPDATE, and no retries in the happy path. For the long tail of 300 million SKUs, where two people rarely buy the same item in the same second, this is the whole answer.

Stock moves through three states. Available units can be held. Held units belong to a checkout that has not finished. Committed units belong to a placed order and leave the count when the warehouse ships them. A hold has a ten-minute expiry so that a buyer who closes the tab on the payment page does not keep the item forever. A sweeper scans for expired holds every few seconds and moves their units back to available, using the hold id so that a late payment confirmation and the sweeper cannot both act on the same hold.

The conditional update serialises on one row. A Postgres row can take somewhere between a few hundred and roughly two thousand such updates a second before lock waits dominate, and on sale morning the headline phone gets 4,000 buy attempts a second. The row becomes a queue, latency climbs past the checkout budget, and connection pools fill up for every other SKU on that shard.

The fix is to split the stock of a hot SKU into buckets. Before the sale, an operator (or a rule that watches add-to-cart velocity) marks the SKU hot and the inventory service spreads its 5,000 units over 32 sub-rows of about 156 units each. A checkout picks a random bucket and runs the same conditional update against it. If that bucket is empty it tries two more at random, then falls back to a scan of the rest. Contention drops by roughly the bucket count, and correctness is unchanged because each bucket is still guarded by its own available >= qty. The cost is that "how many are left" now needs a sum over 32 rows, which is fine for a number you were going to show approximately anyway.

Some teams use a Redis counter with a Lua script for this instead: one DECRBY guarded by a check, at well over 50,000 operations a second on one shard. It is faster, but Redis is now a second source of truth for stock, and you need a reconciliation job and a plan for what happens when a failover loses the last second of writes. Split rows keep a single transactional store and are usually enough. Both are reasonable; pick one and explain the failure you accept.

Checkout spans the inventory shard, an external payment provider and the orders database. There is no transaction that covers all three, and two-phase commit is not available because the payment provider will not take part in it. So the orchestrator runs a saga: a sequence of local steps, each with a compensating step that undoes it.

The orchestrator persists its state after each step, so a crash in the middle resumes from the last recorded step rather than starting over. Every external call carries a key derived from the checkout id, which makes retries safe: a second authorise with the same key returns the first result instead of charging again. Authorise first and capture on shipment is worth calling out, because it means a cancelled or unfulfillable order costs a void, not a refund that takes the buyer a week to see.

The product page shows a stock band ("in stock", "only a few left", "sold out"), not a live count. Inventory emits an event when a SKU crosses a band boundary, and a consumer updates the Redis entry and the search index flag. Between those events the page can be a few seconds behind, which is acceptable because the hold at checkout is the real check. If the page says "in stock" and the hold fails, the buyer sees a clear "just sold out" message with alternatives. That is a better experience than a slow page that tries to be exact.