Live stock or a 15-minute sync? How fresh your inventory really needs to be

An isometric illustration of an online store on a laptop, with a card, a basket, a trolley and cash around it

Every ecommerce brief we receive asks for real-time stock. Roughly a third of them need it. The rest are paying for latency they will never notice, and creating a dependency that takes the store down when the ERP restarts.

This article gives you the numbers to decide. Figures are our own 2026 ranges, in euro.

The question is not technical, it is commercial

There is exactly one thing that matters: how often would a stale number cost you an order you cannot fulfil?

Work it out from your own data. Take a product, look at how many units you sell per day, and ask how likely it is that two customers reach the last unit inside your sync window. For a product selling three units a day, a 15-minute window is a rounding error. For a flash sale on 40 units, even 30 seconds is too slow — you need reservation at checkout, which is a different mechanism entirely.

The freshness question and the overselling question get confused constantly. Faster syncing reduces overselling; it never eliminates it. Only holding stock at the moment of checkout does that.

Three levels, and what each one buys you

  1. Scheduled sync, 15–60 minutes
    • A job pulls changed quantities and writes them to the store.
    • Survives an ERP outage: the store keeps selling the last known numbers.
    • Cheapest to build, cheapest to run, easiest to debug.
  2. Event-driven sync, seconds
    • The ERP pushes a change the moment it happens.
    • Needs a queue, retries and a nightly reconciliation pass, because events get lost.
    • Right for fast-moving lines and small stock depths.
  3. Live read at page load
    • The store asks the ERP for the number every time somebody opens the product.
    • Your ERP is now on the critical path of every page view.
    • Almost never worth it. When the ERP is slow, your store is slow. When the ERP is down, your store is down.

What “live” actually costs

The build cost difference is real but not dramatic — usually 2–3 weeks between a scheduled sync and an event-driven one. The costs that surprise people arrive afterwards:

Load on the ERP. A live read means every product page view becomes an ERP query. A catalogue with 3,000 visitors a day is 3,000+ extra queries against a system that was sized for your accounting team.

A new failure mode. With a scheduled sync, an ERP outage means stale numbers. With a live read, it means an error page. You have coupled the availability of your storefront to the availability of your back office.

Caching, which puts the staleness back. The standard fix for the load problem is a cache with a short TTL. At which point you have built a scheduled sync with extra steps, and a 60-second one rather than a 15-minute one.

If the answer to “what happens when the ERP is down?” is “the shop stops selling”, you have bought the wrong level of freshness.

The MinCode team

The number that decides for you

Pull twelve months of order data and count the lines you had to cancel because the item was not actually there. That figure, as a percentage of total lines, is your decision:

  • Under 0.5% — a 15-minute scheduled sync is correct. Spend the money elsewhere.
  • 0.5–2% — move to event-driven on your fastest-moving 10% of SKUs and leave the rest scheduled. Freshness is not all-or-nothing, and mixing tiers is normal.
  • Over 2% — the problem is usually not sync speed. It is warehouse accuracy, or you are selling the same pool of stock across channels without reservation.

That last case is worth naming. If you sell on your own store, a marketplace and a B2B portal from one warehouse, no sync interval saves you. You need a single source of truth that reserves units as orders land, in the ERP or in a layer above it.

What we build most often

For a store with a few thousand SKUs and a normal sales rhythm: a 15-minute scheduled pull for the whole catalogue, event-driven updates on the top movers, and a nightly reconciliation that compares totals and reports the drift.

Delivery: 3–5 weeks for the scheduled layer, 2–3 weeks more for events on top. It runs on a schedule you can read in a config file, and it keeps selling when the ERP takes its Sunday maintenance window.

How to know it worked

  • Realistic target: cancelled-for-stock lines under 0.3% of total lines;
  • What to watch: drift reported by the nightly reconciliation, which should trend to zero and stay there;
  • Success signal: nobody in the company can tell you what the sync interval is, because it stopped being a problem anyone thinks about.

Let's talk about your project!

Tell us about your project

We reply within 24 business hours with concrete questions and a first estimate.

Done!

Thanks for your message. We'll get back as soon as possible.
Estimated budget