Problem Statement & Context
What we are building and why inventory is hard
Problem Statement & Context
An inventory management system keeps a real-time view of available stock across warehouses, stores, and fulfillment channels. It powers the promise shown to customers ("in stock", "ships today") while coordinating reservations and allocations behind the scenes. In practice it is a distributed consistency problem with heavy writes, time-sensitive holds, and real-world corrections.
The journeys
- Shopper: browse → see availability → add to cart (reserve) → checkout (commit) → ship (decrement).
- Warehouse: receive inbound (update counts) → pick/pack (confirm decrement) → returns (restock or quarantine).
The load-bearing idea: the system never owns stock
The deepest truth of inventory design is that the system does not own the stock — the physical warehouse does. The database is a projection of a physical reality it cannot directly control: boxes get damaged, picks get mis-counted, returns arrive late. So the design has three jobs that follow from that: track the warehouse's truth via events (the warehouse is the source of truth, not the database), hold stock briefly under strong consistency to prevent overselling during checkout, and reconcile continuously because the projection always drifts from reality. The central quantity is Available-To-Promise (ATP) = on_hand − reserved − committed − safety_stock — what you can actually sell right now — and everything else is machinery to keep ATP both fast to read and honest.
Scale anchors
50M SKUs across 500 warehouses; 25M orders/day, 200M inventory reads/day; 5–10× promo spikes. These guide partitioning, caching, and reconciliation frequency.
Key Highlights
- •An inventory management system keeps a real-time view of available stock across warehouses/stores/channels — powers the customer promise ('in stock', 'ships today') while coordinating reservations + allocations; a distributed consistency problem with heavy writes, time-sensitive holds, real-world corrections
- •The load-bearing idea: the system does NOT own the stock, the physical warehouse does — the database is a PROJECTION of a physical reality it can't directly control (boxes damaged, picks mis-counted, returns late)
- •Three jobs follow: track the warehouse's truth via events (warehouse = source of truth, not the DB), hold stock briefly under strong consistency to prevent oversell during checkout, reconcile continuously because the projection always drifts
- •The central quantity is Available-To-Promise (ATP) = on_hand − reserved − committed − safety_stock (what you can actually sell now); everything else is machinery to keep ATP fast to read + honest; anchors 50M SKUs × 500 warehouses, 25M orders/day, 200M reads/day, 5-10× spikes
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will treat inventory as a promise and protect it with reservations."
- "We will reconcile system counts against warehouse truth regularly."