Inventory synchronization
Keeping one true stock count across every place you sell, so the last unit doesn't get sold three times on three channels.
See it
What it is
Inventory synchronization is the plumbing that keeps one stock number true everywhere you sell: your own storefront, Amazon, eBay, Etsy, TikTok Shop, the retail POS, the 3PL's warehouse system. Pick a single source of truth (usually an ERP, OMS, or the 3PL feed), then push absolute counts out to every channel rather than sending deltas, because a missed '+3' message corrupts the count forever while a missed 'set to 12' is fixed by the next update.
The failure mode has a name: overselling. Sell the last unit on two channels within the same sync window and someone gets a cancellation email, a refund, and on marketplaces a defect rating that can suspend your listings. Marketplaces also do not update instantly (Amazon feeds settle in minutes, not milliseconds), so real-time sync is a goal, not a guarantee.
The practical fix is not faster polling, it is buffer stock: hold back a couple of units per SKU on high-velocity channels so the sync lag has something to eat. Add to that an expiring reservation taken at checkout or payment authorization (not when someone adds to cart, or one abandoned session holds your last unit hostage), idempotent webhook handling so a replayed message does not double-count, and per-location tracking if you ship from more than one place. Bundles are the sneaky part, and only one kind of them: a virtual bundle decrements every component SKU inside it at sale, while a fixed preassembled bundle is its own SKU with its own stock and decrements only itself. Refunds are the other trap: a refund is a payment event, not a stock movement, so nothing goes back on the shelf until a physical return is received and inspected.
Ask AI for it
Design an inventory sync service for a multi-channel store. Treat the warehouse system as the source of truth, expose stock per SKU per location, and push absolute quantities (not deltas) to each sales channel. Drive stock changes from inventory events only: reservation created and expired, order accepted, order cancelled, fulfillment shipped, stock received, and return inspected. Treat a refund event as a payment state change that moves no stock at all, and restock a unit solely when an approved return disposition says it is sellable. Handle every event idempotently with an event ID so replays cannot double-count, and fall back to a full reconciliation sweep every 15 minutes to catch dropped events. Support a configurable buffer quantity per channel, reserve stock at checkout with a timed release for abandoned sessions, decrement component SKUs when a virtual bundle sells (a fixed bundle SKU decrements only itself), and log every stock movement to an append-only ledger. Alert when a channel's count drifts from the source of truth or a SKU goes negative.