A D2C skincare brand in Mumbai sells the same 200ml serum on its own Shopify store, on Amazon, on Flipkart, and through a quick-commerce partner. On a Saturday sale day it has 40 units left. Four channels, each holding its own cached view of that number, each accepting orders. By Sunday morning the brand has confirmed 53 orders and has to cancel 13 of them. On Amazon, that pushes the order defect rate up and edges the account closer to a listing suspension.
This is the overselling problem, and it is almost never caused by bad counting. It is caused by time.
Sync Latency Is the Real Variable
Every channel integration has a refresh interval. Many marketplace connectors poll on a schedule, commonly every 10 to 15 minutes for stock levels, and some push updates in batches every hour during peak load. Between two polls, a channel is selling against a stale number. If a SKU moves 5 units a minute during a flash sale, a 10 minute window is 50 units of exposure on a single listing.
Three things widen that window in practice:
- Batch update caps. Marketplace APIs throttle bulk inventory calls. A catalogue of 5,000 SKUs pushed at 100 items per call runs into rate limits well before it finishes a full cycle.
- Queue backlogs. When an order webhook fails and retries, the stock decrement it should have triggered sits in a dead-letter queue rather than reaching the other channels.
- Manual edits. Someone adjusting a count in a marketplace seller panel creates a value the central system does not know about until the next reconciliation.
Buffers Are a Blunt Instrument
The common workaround is a safety buffer: hold back 10 or 15 percent of stock from each channel so no channel can sell what does not exist. It works, and it is expensive. On a catalogue with a 60 day average sell-through, a 15 percent buffer is roughly nine days of inventory sitting unsellable. For a brand carrying 2 crore in stock, that is capital parked to compensate for an engineering gap.
Better patterns exist. Dynamic buffers scale with velocity, so a slow-moving SKU carries almost no reserve while a fast mover carries a larger one. Channel-tiered allocation assigns pools deliberately, protecting the higher-margin owned store rather than treating all channels equally. Both need a single authoritative stock ledger to work from.
Build Around One Source of Truth
The architecture that holds up is straightforward in principle. One inventory service owns the true available-to-promise number. Every channel is a subscriber, never an owner. Orders decrement through a reservation model, where stock is held at cart or checkout initiation with a short expiry rather than at order confirmation. Reconciliation runs on a fixed cadence, comparing channel-reported stock against the ledger and flagging drift above a threshold instead of silently overwriting.
Two operational habits matter as much as the code. Measure sync lag per channel as a first-class metric, with alerts when the ninety-fifth percentile crosses your tolerance. And track cancellation reasons at line-item level, because an oversell rate above roughly 1 percent is a signal that buffers are masking a problem rather than solving one.
At Invexa, we treat inventory accuracy as a system property rather than a reporting exercise, so the ledger, the reservation logic, and the channel connectors are designed together from the first sprint.