A quick-commerce platform holds inventory across hundreds of dark stores that changes continuously. Which inventory data must be strongly consistent, which can be cached, and what should happen at checkout when the cached view is stale?

The three views of inventory, and their different requirements

• Browse availability (is this roughly in stock near you): cached aggressively, seconds to a minute stale, served from a per-store projection. Serving this from the authoritative store would put the entire browse load on the system that must never be slow.
• Basket validation (still available as you add items): fresher, tens of milliseconds stale, read from a per-store cache updated by change events. Still not authoritative.
• Checkout reservation (commit this stock to this order): strongly consistent, single writer per store-SKU, transactional. This is the only one that must be exact, and it is a small fraction of the traffic.

The design insight is that the expensive guarantee is needed on the cheapest path. Checkout volume is a fraction of browse volume, so the strongly consistent component is small and can be scaled and protected independently.

What happens when the cached view was wrong

The reservation fails, and the design question is what the customer experiences. The bad answer is a generic error at the payment step. The good answers, in order of preference:

• Substitute, offering an equivalent item, decided before payment.
• Partial fulfilment with an explicit price adjustment, if the basket is still worth delivering.
• Remove and re-price, with a clear message, if the item is unavailable and unsubstitutable.

All of these require the reservation to happen before payment authorisation, not after — which is a sequencing decision made early and expensive to change later.

The reservation's own design

• Time-bounded. A reservation that is never released leaks stock, and the release must be enforced server-side because an abandoned client cannot release its own.
• Idempotent, so a retrying client does not reserve twice.
• Recorded as a ledger entry, not a decrement. A counter that goes up and down has no history; a ledger of reservations and releases can be audited and reconciled against physical stock, which is the only way to find the discrepancy between what the system believes and what is on the shelf.

What makes this domain different

Physical stock drifts. Items get damaged, mis-picked, or counted wrong, so the system's number is always an estimate of a physical fact. That argues for safety stock — reserving less than the full count — and for periodic reconciliation against physical counts, neither of which is a software consistency problem at all.