If you've ever built inventory sync across multiple marketplace APIs, you've hit this wall.
Amazon doesn't know what sold on Shopify. Shopify doesn't know what sold on eBay. Each platform maintains its own isolated inventory record. They all draw from the same physical stock. And none of them communicate natively.
The standard fix is a scheduled sync job. Every 15 minutes, pull the master count, push updates to every channel. Simple. Works fine at low volume. Falls apart completely under concurrent load.
Why polling breaks down
A 15-minute sync window is 15 minutes of exposure. During that window, every channel believes it has stock that may already be sold elsewhere. At low volume you get lucky most of the time. During a flash sale, a viral product moment, or — increasingly — an AI shopping agent recommending your product to millions of users simultaneously, you don't get lucky. You get oversells.
The deeper problem is the last-write-wins failure mode. If two channels both decrement their local count between sync cycles, the next polling run overwrites one of those decrements with a stale value. You don't just fail to prevent the oversell — you actively undo a correct decrement that already happened.
At scale, polling-based sync doesn't just lag. It actively corrupts state.
The event-driven alternative
The correct architecture treats every sale as an event that immediately propagates to every connected channel. Instead of a scheduled job that periodically checks for changes, the system reacts the moment a change occurs.
When a sale fires on any channel, three things happen in sequence. The master inventory record decrements atomically. The new quantity fans out to every other connected channel. The result confirms back to the originating channel.
The word atomic matters here. When two orders arrive simultaneously from different channels for the same last unit, only one can succeed. The other must fail cleanly as an out-of-stock response — not as a confirmed oversell. Without atomic operations at the database layer, both succeed. Both channels confirm. You're negative one unit with two orders you can't fulfill.
A conditional decrement that only executes if quantity is greater than zero, and returns nothing if it isn't, gives you this guarantee regardless of how many concurrent requests arrive simultaneously.
Webhook reliability is the hard part
The event-driven model depends on receiving a notification every time a sale happens on any channel. Marketplaces deliver these through webhooks — HTTP callbacks that fire on specified events.
Webhook reliability varies significantly across platforms and this variance is where most implementations break down.
Shopify webhooks are reliable but must be acknowledged within five seconds. Any processing that takes longer than five seconds triggers a retry. Your handler must respond immediately with a 200 and process the payload asynchronously. Failing to do this means retries stack up during any processing delay and you end up handling the same event multiple times.
Amazon uses SNS for notifications with retry logic that can fire the same message up to 100,000 times with exponential backoff. Without idempotency guarantees, a single network hiccup becomes 100,000 duplicate inventory decrements.
WooCommerce webhooks are reliable but lack the delivery guarantees of hosted platforms. You need your own reconciliation layer to catch missed events rather than relying on platform-level retry logic.
The pattern that works across all platforms: acknowledge immediately, process asynchronously, check idempotency before acting.
Idempotency is non-negotiable
Every platform retries webhooks on failure. This is correct behavior — it ensures events are delivered even when your handler is temporarily unavailable. But retrying without idempotency means processing the same event multiple times. You decrement inventory twice for one sale. You're now showing phantom stock reduction that makes you appear to have less inventory than you actually do.
Every event needs a unique identifier. Every processed event identifier needs to be stored. Before processing any incoming event, check whether you've seen the identifier before. If you have, return the cached result without reprocessing. If you haven't, process the event and store the identifier.
The check and the insert must be atomic — a non-atomic check creates a new race condition where two concurrent deliveries of the same event both pass the check before either inserts the record.
Store processed event identifiers with a retention window longer than the longest retry period of any platform you integrate with. Amazon SNS retries for up to 23 days with default configuration. A 30-day retention window covers all realistic scenarios with a comfortable buffer.
Reconciliation as a safety net
Even with webhooks and atomic operations, events get missed. Network partitions happen. Platform webhook systems have outages. Deployments create brief unavailability windows.
The fix is a reconciliation job that runs periodically and compares your master inventory against each channel's reported count. Any discrepancy gets corrected by pushing the master record's value to the drifted channel. Run this hourly. The master record is always correct by definition — channels that drift are corrected from it, never the other way around.
In practice, hourly reconciliation catches roughly two to three percent of events that the real-time webhook layer misses. Small enough that the system is reliable under normal conditions. Large enough that you would notice immediately if reconciliation stopped running.
The AI commerce complication
Something worth noting for anyone building ecommerce infrastructure in 2026: AI shopping agents have made inventory accuracy a discoverability metric, not just an operational one.
ChatGPT, Google Gemini, and Perplexity now recommend and sell products directly to consumers. These agents read your real-time inventory status. Products that are consistently in stock when recommended build a positive track record with the recommendation algorithm. Products that lead to out-of-stock experiences get deprioritized.
The practical implication: a sync delay that was operationally acceptable at 500 units in stock is now costing you AI recommendations at any stock level. The stakes on inventory accuracy went up by an order of magnitude when AI agents with access to hundreds of millions of users started making purchase decisions based on your data.
The architecture that works
Sale event on any channel fires a webhook. Handler acknowledges immediately and queues payload for async processing. Worker checks idempotency key — skips if already processed, proceeds if new. Atomic conditional decrement executes against master inventory. Fan-out pushes updated quantity to all connected channels. Event identifier stored as processed. Hourly reconciliation validates all channel counts against master record and corrects any drift.
Each layer handles a specific failure mode. Atomic operations prevent race conditions. Async processing prevents webhook timeouts. Idempotency prevents duplicate decrements. Reconciliation catches missed events. Together they give you inventory consistency across any number of channels under concurrent load.
We implemented this architecture across 34 marketplace integrations at https://nventory.io — Shopify, Amazon, Flipkart, WooCommerce, TikTok Shop, and more. Sub-10 second propagation under normal load. The reconciliation layer catches the edge cases the event stream misses. The system has been running in production long enough to say with confidence: the architecture works. The operational discipline of treating the master record as the only source of truth is harder to maintain than the code.
This is a really strong, real-world breakdown of a problem most teams underestimate until it starts costing them money. The shift from polling to event-driven architecture is clearly not just an optimization, it’s a necessity once concurrency and scale enter the picture.
What stands out is how well the failure modes are addressed layer by layer. Atomic operations handle race conditions, idempotency protects against retries, and reconciliation acts as a safety net. That kind of layered thinking is what makes systems resilient rather than just functional.
The point about AI-driven commerce is especially interesting. Inventory accuracy moving from an operational concern to a discoverability signal changes the stakes completely. It’s no longer just about avoiding oversells, it’s about maintaining trust with recommendation systems.
From a quality perspective, this kind of architecture benefits a lot from structured validation. Testing concurrent scenarios, webhook retries, and reconciliation logic is not trivial, and having a clear way to track these edge cases becomes important. Tools like Tuskr (https://tuskr.app/ ) can help teams organize and validate these complex workflows, ensuring that reliability holds up not just in theory but in production conditions.