Every inventory tool syncs one of two ways. Batch sync runs on a clock: every 15 minutes (or hour, or day) it collects changes and pushes them around. Real-time sync runs on events: a sale happens, and within seconds every other channel knows. The distinction sounds technical; operationally it is the difference between preventing an oversell and explaining one.
How each actually works
Batch: the tool polls each channel on a schedule, computes what changed, and writes updates outward. Simple to build, gentle on APIs, and mathematically guaranteed to be stale between runs, the average staleness is half the interval, the worst case the full interval.
Real-time (event-driven): channels notify on events (a sale, a stock edit) or are watched continuously; each event immediately triggers updates everywhere else. Harder to engineer, and structurally fresh: staleness is measured in seconds of processing, not minutes of waiting.
What the interval costs, concretely
Take a 15-minute batch cycle, the most common “automatic sync” in the category:
- A unit sells on eBay at 14:02. Amazon, Etsy, and your store keep offering it until the 14:15 pass.
- Any sale of that unit anywhere in those 13 minutes is a double-sell: a cancellation, a defect on a marketplace scorecard, and a refund with shipping apologies.
- The probability scales with velocity and thinness: deep-stocked slow movers rarely collide inside the window; promotions, spikes, and last-units inventory collide constantly, which is why batch-sync failures cluster on your best days.
Batch’s real costs hide in the tails: the flash-sale hour, the viral listing, the quantity-1 collectible. Averages look fine; the incidents are all at the edges.
When batch is genuinely fine
Honesty about the other direction:
- Catalog and content data (titles, descriptions, images) changes rarely and tolerates staleness, batch is the correct, efficient choice there.
- Deep stock, slow velocity: fifty units of a once-a-week seller cannot realistically double-sell in 15 minutes.
- Analytics pipelines: reporting a day behind is a non-problem.
The failure is not batch itself; it is batch applied to live availability on inventory that moves.
The questions that expose a vendor’s architecture
Marketing has blurred “real-time” past usefulness, several tools whose own documentation specifies 15-minute or per-day cycles use the phrase freely. Cut through with three questions:
- “What is the maximum time between a sale on channel A and the updated count on channel B?” Seconds is real-time. Any answer with “minutes” is batch.
- “Is the sync event-driven or scheduled?” Watch for the word “frequency”, frequencies belong to schedules.
- “Show me the sync log.” Event-driven systems log per-event pushes with timestamps; batch systems log runs. The log never lies, verifiability matters beyond speed.
Unifystock’s answer to the first question is under three seconds, event-driven, with a per-channel sync-health log you can audit, and that architecture, not a plan tier, is why the number is what it is.
Common questions
Is real-time sync harder on marketplace API limits?
Done correctly it is gentler: event-driven systems act only when something happens, while batch polls everything on every cycle whether anything changed or not.
Can I mix the models?
That is the correct design: real-time for counts and prices, batch for content and analytics. Judge each data type by its staleness tolerance.
My tool syncs every 5 minutes - close enough?
Five minutes is a fivefold improvement on 15 and still a window. Thin, fast SKUs deserve seconds plus a buffer; the rest of the catalog may never notice. Know which SKUs are which.
Does real-time matter for a single channel?
No, one channel has no counts to reconcile. It matters from the second channel onward, and the moment it matters, it matters completely.
Buy the architecture, not the adjective
Ask for the number in seconds, then verify it in the log. Ours is under three, on every plan, from $49/month with unlimited orders. See pricing.