Trex Pi
Every retailer we meet has the same story: the webshop sold three units of something the warehouse had zero of, an angry customer email followed, and someone declared the integration "broken". It usually isn't. It is doing exactly what it was designed to do - sync stock every 15 minutes - and the design is the problem.
Overselling is a consistency question
Stock sync sits on a spectrum between two costs:
- Sync too rarely and you sell what you don't have.
- Reserve in real time and you pay for it - in ERP API load, in checkout latency, and in engineering complexity.
The mistake is picking one point on that spectrum for the entire catalogue. A retailer with 40,000 SKUs might have 200 that ever get close to overselling - fast movers, promotion items, last-unit clearance. Those deserve real-time reservation at checkout. The other 39,800 are perfectly served by a 15-minute batch feed.
The three-tier model we ship
- Batch tier - the default. Stock levels flow ERP → webshop on a schedule. Cheap, robust, fine for anything with healthy stock depth.
- Threshold tier - when on-hand quantity drops below a configurable floor, the SKU is promoted to event-driven updates automatically.
- Reservation tier - checkout places a hard reservation in the ERP before confirming the order. Reserved for the handful of SKUs where an oversell costs more than the API calls.
The promotion between tiers is automatic and data-driven - the integration watches its own miss rate and adjusts. Six months after shipping this for a Baltic retail group, oversells went from a weekly incident channel to two cases a quarter, and both turned out to be stock balances corrected by hand in the warehouse - a data-entry error at the source, not a fault in the sync.
Design the integration around the cost of being wrong, and the architecture follows.