The Draft Order That Committed Inventory It Never Paid For

The storefront said sold out on a variant that the warehouse said was on the shelf, and the number of such variants grew daily, and the inventory was not lost, it was reserved, by draft orders that were created and abandoned, and the reservation happens at creation, not at payment, so the abandoned draft held the stock, and the hold had no expiry, and the days of abandoned drafts accumulated into the sold out, which was the stock committed to orders that would never complete, which is the leak, and the leak is a draft order's property: it reserves at birth and releases at nothing.

This is the anatomy of the unexpiring reservation, and of the property that makes it invisible: the draft order looks inert, it is a draft, it has not been paid, so it does not feel like a commitment, but the inventory system treats the reservation as a commitment, and the draft's inertness is the illusion, because the stock is committed from the moment the draft exists.

This was Shopify, with a headless front end creating draft orders for every cart, and the carts abandoned at the usual rate, and the rate times the days was the stock, which is the arithmetic of the leak.

The reservation is a commitment

I have chased this from the revenue end and from the reservation's lifetime end, and the truth was in the hand-off, as it usually is.

The reservation is correct, and its lifetime is the bug, and the lifetime's absence is the leak, and the leak is a TTL that does not exist, which is the same missing TTL as the cart session that leaked memory, same mechanism, different costume.

Why the draft is created eagerly

The front end created the draft at cart creation, because the draft is the cart's server side identity, and the identity is created when the cart is created, which is the eager creation, and the eager creation is the leak's source: the draft exists for every cart, including the carts that never checkout, and the cart abandonment rate, the majority, means the majority of drafts are abandoned, and the abandoned drafts are the reservations, and the reservations are the stock, and the rate is the leak's multiplier, which is the arithmetic: the carts per day, times the abandonment rate, times the average items, is the stock reserved per day, accumulating without the TTL, which is the leak's slope.

The reconciliation that finds the leaks

The reservation leak is found by the reconciliation: the inventory's available quantity, and the sum of the draft reservations, and the sum of the completed orders' quantities, and the reconciliation shows the available minus the reservations is less than the physical, which is the stock committed to drafts, and the drafts' ages show the accumulation, the old drafts holding stock, which is the leak, and the reconciliation is the measurement, and the measurement is the audit, which is the leak's discovery, because the inventory alone does not show the reservation's age, and the age is the leak.

This is the reconciliation discipline from the ledger that showed the slowest queries, which is why the two fixes look alike.

The fixes

Give the draft a TTL. The draft expires after a window, an hour, a day, and the expiry releases the reservation, and the release returns the stock, and the window is the leak's bound, so the reservations do not accumulate past the window, and the window is set by the checkout's expected duration, which is minutes, so the window is generous at an hour, and the hour is the bound, and the bound is the fix, the TTL that was absent.

Reserve at checkout, not at cart. The reservation's trigger is the checkout's start, not the cart's creation, so the abandoned carts do not reserve, and the reservation's population is the checkouts, the committed intent, which is the smaller set, and the smaller set is the leak's shrinkage, at the source, the trigger moved to the intent.

Reconcile on a schedule. The daily reconciliation, the available minus the reservations minus the completed, flags the drift, and the drift is the leak's signature, and the reconciliation's alert is the leak's detection, and the detection is the tripwire, which is the audit made a schedule, so the leak is found at one day, not at the sold out, which is the detection moved from the symptom to the drift.

Release on the draft's expiry, explicitly. The release is an action, an API call, or the platform's expiry, and the action is logged, and the log is the release's evidence, and the evidence is the reconciliation's input, which is the loop closed: the reservation, the expiry, the release, the log, the reconciliation, and the loop is the leak's absence, because every reservation has a release, and the release has a record.

What I now do

A draft order reserves inventory at creation, and the reservation outlives the draft unless released, so abandoned drafts accumulate committed stock that the storefront shows as sold out. Give the draft a TTL, reserve at checkout rather than at cart, reconcile the reservations daily, and release explicitly on expiry.

The sold out items were in the warehouse. They were reserved by orders that would never pay, and the reservations were correct, and their lifetimes were absent, and the absence is the leak. I now check for that property first, because it is where the failure actually lives.