Inventory Sync: Why Overselling Happens and How to Stop It

Selling the same last unit twice costs a refund, a review and a customer. The fix is architectural, not a faster sync.

You list on your own store, a marketplace and a retail point of sale. Each holds its own idea of stock, and a sync job reconciles them every fifteen minutes. Then two customers buy the last unit within the same window, and no amount of syncing faster will have prevented it.

Why faster sync does not fix it

This is a race condition, not a latency problem. As long as several systems can each independently commit a sale against their own copy of the stock number, simultaneous sales will oversell. Reducing the interval reduces the frequency and hides the cause, which is worse — it fails rarely enough that nobody fixes it, and always on the busiest day.

The three workable approaches

1. Single source of truth. One system owns stock; every channel checks and decrements against it at the moment of sale. Correct, and the right target if volume justifies the work.
2. Allocation per channel. Split the stock explicitly — 6 units here, 4 there — so channels cannot conflict. Simple and safe, at the cost of unsold allocated stock.
3. Safety buffer. Publish stock minus a threshold, sized from your actual concurrency. Crude but effective, and the fastest thing to implement this week.

Handling the failure well

Overselling will still happen occasionally. Decide the response before it does: notify within minutes rather than at end of day, offer an alternative or an immediate refund plus something small, and never let the customer discover it from a shipping delay. Most of the damage comes from the silence, not the mistake.

• 15min sync window where races happen
• 1 system that owns the number
• minutes to notify, not days