A retailer's website must show whether an item is available in a nearby store. Store systems are occasionally offline and physical counts drift from recorded counts. How should availability be modelled?

What is being tested

Whether you can design against a constraint that is physical rather than technical — the fact that the database is not the system of record for reality.

The constraint

Recorded inventory is an estimate of what is on a shelf. It drifts because of theft, damage, misplacement, items in a customer's basket, receiving errors, and picking in progress. It is corrected only by periodic counts. No amount of transactional rigour in the database makes the number true, because the truth is in the building.

This is the mistake to avoid: modelling stock as a strongly consistent integer and building elaborate locking to protect it. That protects the record, not the reality, and the record was never accurate.

The design that follows

Model availability as a probability, expose it as a category. Internally hold a confidence estimate that combines recorded count, time since last count, sales velocity, and historical drift for that item and store. Externally show "in stock", "low stock", or "check store" — categories the customer can act on and that do not overstate certainty.

Use safety buffers that vary by item. Do not offer the last two units of a high-shrinkage item for pickup. The buffer is a business parameter, tuned per category, not a constant.

Make reservation a real state with a lifetime. When a customer commits, decrement an available pool and hold it with an expiry, so two customers cannot be promised the same unit. This is a soft reservation over an estimated pool — not a lock over a true count — and it should be described that way.

Design the failure path as a first-class flow. Sometimes the item will not be there. That is not an exception; at retail scale it is a daily event affecting many orders. Substitution rules, partial fulfilment, automatic refund and proactive notification are core product flows and should be built with the same care as checkout.

Let stores keep selling when disconnected. If the link to the centre is down, the store must continue to transact locally and reconcile afterwards. This is an availability-over-consistency choice made deliberately, because a store that cannot sell is a worse outcome than a count that is briefly wrong.

The peak, which is the other half of the constraint

Retail peaks are known years in advance. That changes the capacity strategy: pre-provisioning and load testing against a known date is rational, where an unpredictable workload would demand elastic autoscaling. It also means change freezes are legitimate — the cost of a bad deployment on the highest-revenue day of the year exceeds the value of any feature shipped that week.

What a strong answer adds

The observation that different channels tolerate different accuracy. Ship-from-warehouse can be near-exact because the warehouse is instrumented. Store pickup is an estimate. Same product, same company, different consistency guarantees — and the architecture should say so explicitly rather than pretending to a single truth it does not have.