Guides

What "real-time" actually means in inventory sync

Every sync app claims real-time. The claim covers three very different mechanisms, only one of which holds up under load. How the pipeline really works — webhooks, conditional writes, reconciliation — and the questions that expose which mechanism you are buying.

“Real-time” is the most-used word in this category and the least load-bearing. It has no agreed meaning, so it stretches to cover three mechanisms with genuinely different behaviour — one of which degrades exactly when your store is busiest. This page is the decoder: what actually happens between a sale in one store and a corrected number in another, and where each mechanism quietly fails.

It stays deliberately close to the mechanics. For the merchant-facing consequences — what the failure costs and the patches people try — see how overselling actually happens.

The three things “real-time” is used to mean

1. A fast schedule. The app polls every minute or five and calls it real-time. The interval is the window of wrongness, and — the structural problem — a schedule degrades under load: more sales land inside each interval exactly when you are busiest. A fast schedule is a slow schedule with better marketing.

2. Event-driven, blind write. The app subscribes to Shopify’s inventory webhook, reacts in seconds, and writes the new number to the destination. Trigger: right. Write: wrong. Read-compute-write with a plain overwrite can lose a race — a sale lands in the destination between the read and the write, the overwrite restores a stale number, and the sync has now caused an overstatement. Under load this is not rare; simultaneous sales are what load is.

3. Event-driven, conditional write. Same trigger, but the write says: set the quantity to X, provided it is still Y, which this was computed from. If the destination moved, the write is rejected and recomputed against reality. This is the only version of “real-time” whose correctness does not depend on being lucky about timing.

The pipeline for the third, concretely: a sale changes an inventory level → Shopify emits the inventory-level webhook → the app maps the SKU to its destination counterpart → conditional write via the API → on rejection, re-read and retry. Latency: low single-digit seconds in the ordinary case, longer under API rate limits — which is honest, and fine, because the guarantee that matters is convergence, not the stopwatch.

The part the marketing never mentions: missed events

Shopify’s webhook delivery is at-least-once — duplicates and delays are normal, and after repeated delivery failures (an app outage, an unlucky window) an event can be missed for good. A sync built purely on webhooks is therefore a system whose failure mode is silent, permanent drift: nothing is wrong on any dashboard, one number is simply stale forever.

The fix is unglamorous: reconciliation. Periodically compare actual quantities across every matched SKU and surface every mismatch. Any vendor whose real-time story does not include a reconciliation story is describing the happy path only — and drift you cannot see is the expensive kind.

The test you can run yourself, no vendor required: change a quantity in the source and time its arrival in the destination — that verifies the trigger. Then edit a quantity directly in the destination and watch what happens: a well-built one-way sync should detect the divergence (or overwrite it on the next source change), and its drift report should have something to say about it. The second test is the informative one, because it probes the path where things actually go wrong.

The decoder table

These are fair questions for any vendor, this one included — the seven-question guide generalises them across the whole category.

Where StockUnison sits

StockUnison is mechanism three with the backstop: triggered by Shopify’s inventory webhook, writing with compare-and-set (a rejected write is recomputed, never forced), and reconciled by a difference report that compares every matched SKU across stores — because we assume webhooks go missing, ours included. Every write and every refusal lands in the log, and failed writes surface rather than vanish.

What it does not claim: the window is seconds, not zero — no cross-store sync can make two stores one database, which is why the difference report exists. It is one-way only, and syncs quantities, not products. The free plan includes the difference report, which means the reconciliation half of this page can be had without paying — including as an audit running beside whatever sync you use today.