Applications · Implementation study
Inventory that stays correct across locations
Stock records that survive concurrent movements, reflect what is actually committed, and tell someone before a shelf runs empty.
What the demo shows
The locations, SKUs, quantities, and reorder alerts shown are fictional sample data with local controls. Nothing is connected to a warehouse system, purchasing workflow, or supplier feed.
Proposed system flow
- 01Stock movement
- 02Serialized write
- 03Available-to-promise
- 04Reorder signal
01
Record movements, then derive the count
The durable design stores an append-only ledger of stock movements, receipts, transfers, adjustments, and shipments, and treats the on-hand quantity as a value derived from that ledger rather than a single mutable number. A stored count that is updated in place loses its own history: when it disagrees with the shelf, and it eventually will, there is nothing to reconstruct. A movement ledger answers who changed what, when, and against which document, and lets a cached running total be rebuilt whenever it is doubted. Each movement carries an idempotency key so a retried scan or a redelivered webhook cannot silently double-count a pallet.
02
Let the database arbitrate concurrent movements
Two devices decrementing the same SKU at the same moment is the ordinary case in a warehouse. Reading a quantity into application memory, subtracting, and writing it back loses one of those movements whenever they interleave. The write has to happen as a conditional update the database evaluates, under an isolation level chosen deliberately, so that an oversell attempt fails loudly instead of producing a negative balance nobody notices until picking. Where a genuine sequence matters, taking an explicit lock on the item row for the length of the transaction is clearer than hoping the ordering works out.
03
Distinguish on hand from available to promise
On hand, allocated, in transit, and available to promise are four different numbers, and most inventory disappointments come from an interface that shows one of them and lets a customer act as though it were another. Stock reserved for a picked order is not available, stock on a truck is not yet receivable, and stock in a quarantine location may not be sellable at all. Making those states explicit in the model, and showing the one relevant to the decision at hand, is what stops a website promising same-day delivery on a unit already committed to somebody else.
04
Make the reorder signal something a person can act on
A reorder point is only useful if it reflects how fast the item actually moves and how long the supplier actually takes, both of which drift. Recomputing from recent demand and observed lead time, rather than a number typed in once at setup, keeps the alert meaningful. The alert itself needs an owner, a suggested quantity, and a link to the purchasing action, because a dashboard badge nobody is responsible for clearing gets ignored at exactly the same rate as no alert at all.
Validation plan
- Run concurrent movements against the same SKU from multiple clients and confirm no lost updates, no negative balances, and a clear failure for the movement that could not be satisfied.
- Rebuild on-hand quantities from the movement ledger and reconcile against the cached totals, treating any divergence as a defect.
- Verify a replayed scan or redelivered integration message with the same idempotency key does not move stock twice.
- Compare system counts against a physical cycle count per location and track the variance over time rather than correcting silently.
More in applications
Have a similar problem to solve?
Discuss your project