A B2B commerce platform aggregates inventory from many suppliers whose feeds arrive asynchronously with different frequencies and reliability. How should stale inventory, safety stock, reconciliation and supplier failures be handled?

The core problem

You do not have inventory; you have a set of claims about inventory, each with an age and a source reliability. Modelling those claims as though they were facts is what causes the failure — an order accepted against a number that was true nine hours ago.

What the model must carry

Every quantity should be stored with its as-of timestamp, its source, and a confidence derived from that source's history. Then downstream decisions become explicit rather than accidental:

• Fresh and reliable: sell it.
• Fresh but from an unreliable supplier: sell it with safety stock withheld.
• Stale: show as available with a longer promised lead time, or hide it, depending on the category.
• Very stale or supplier feed failing: stop selling and alert, rather than continuing to sell into an unknown.

The mistake is a single availability boolean, because it forces one policy across sources with wildly different reliability.

Safety stock as the primary control

Selling only a fraction of claimed stock is a blunt instrument and it is the most effective one available, because it converts an unpredictable failure into a predictable cost. The fraction should be per supplier and learned from their fulfilment history, not a global constant — a supplier who has never failed and one who fails a tenth of the time should not be treated identically.

Handling supplier feed failures

• Distinguish "no update" from "zero stock". A feed that stops is not a supplier with nothing in stock, and conflating them either hides good inventory or sells inventory that is gone.
• Age out claims explicitly with a per-supplier staleness threshold.
• Isolate suppliers from one another — a slow or broken feed must not block ingestion for everyone, which means per-supplier workers, queues and error handling.
• Reconcile against fulfilment outcomes, which is the only feedback that tells you whether the claims were true. A supplier's confidence score should be derived from orders they actually fulfilled, not from how often they send a file.

The business consequence to design for

Some orders will be accepted and not fulfillable. The architecture needs a defined path — substitution, split shipment, cancellation with a refund and a supplier penalty — and the frequency of that path is a metric the business manages, not a bug the engineers eliminate.