Design a Global Inventory Tracking

Problem statement

Design a global inventory tracking system for a large e-commerce retailer operating roughly 200 warehouses and distribution centers across 12 regions. The system must give every shopper, seller, warehouse operator, and planner one coherent view of stock: how many units of each SKU exist, where they physically sit, how many are already committed to open orders, and how many can still be promised. It must ingest real-time stock changes from receiving, sales, returns, transfers, and cycle counts; expose warehouse-level available and committed quantities; trigger automatic replenishment when stock falls below computed thresholds; and feed location-aware sourcing so orders ship from the cheapest viable warehouse.

This is not a CRUD table with a quantity column. The hard part is that three hostile forces act on the same number at once: thousands of warehouse devices mutate physical truth (receiving, picking, damage, theft), millions of shoppers concurrently reserve the same hot units, and replenishment planners inject future supply into the same availability math. A stale read becomes an oversell: the shopper buys unit 43 when only 42 exist. A lost write becomes phantom stock: the catalog promises units nobody holds, and every downstream promise is a lie. Inventory is also money — finance values the balance sheet from these numbers, so every mutation needs an auditable, replayable trail.

Why the problem is distinctive

A product catalog tolerates seconds of staleness; a payment ledger tolerates none. Inventory lives between them and must therefore be split by access pattern. The authoritative unit count per SKU per warehouse is a strongly consistent, single-writer aggregate — effectively a distributed ledger. The views derived from it (regional availability, PDP counts, seller dashboards) are eventually consistent projections with declared freshness. Reservation holds sit in a third tier: strongly consistent leases that convert browse traffic into committed stock without blocking the ledger.

Public operating signals

The category operates at enormous real scale. Shopify reported 4.2 million checkouts per minute at its BFCM 2023 peak — company-published figure — which means availability checks and reservation writes in the tens of thousands per second for its merchant base. Amazon said shoppers bought more than 375 million items worldwide during Prime Day 2023, its own reported number. Inditex (Zara) completed RFID tagging of every garment, roughly 3 billion items a year by company statements, making per-unit stock visibility operationally real rather than theoretical. These anchor the plausibility of the design; the capacity numbers used below for sizing are explicitly labeled assumptions.

The four architectural planes

1. Mutation plane: warehouse management systems, receiving scanners, returns desks, transfer crews, and cycle-count teams emit signed, sequenced stock events.
2. Ledger plane: one authoritative, append-only ledger per SKU-per-warehouse aggregate, serializing every decrement, increment, reservation confirm, and adjustment.
3. Projection plane: availability-to-promise (ATP), regional rollups, seller and catalog caches, rebuilt from ledger events with bounded staleness.
4. Replenishment and sourcing plane: reorder-point evaluation, purchase-order emission, and nearest-warehouse sourcing decisions driven by projections but fenced from double action.

A strong answer keeps these planes separate: the ledger never serves browse traffic, projections never authorize a decrement, and replenishment never writes stock directly — it proposes, the ledger decides.