Overview
Inventory is the operational foundation of e-commerce. Every other part of the business — the storefront, the marketing, the fulfilment — depends on stock level data being accurate. When it is not, the consequences are immediate: overselling products that are not in stock, underselling because available stock is not correctly reflected, customer orders that cannot be fulfilled, and the operational cost of manually reconciling stock levels that should have been synchronised automatically.
The synchronisation problem becomes acute the moment a business sells across more than one channel. A sale on Bol.com reduces stock that is also listed on Shopify, on Amazon, and in the physical store. If those reductions do not propagate instantly and accurately, overselling follows. The more channels, the more fulfilment locations, the more suppliers feeding stock in from different directions — the more complex the synchronisation problem becomes, and the more costly the consequences of getting it wrong.
We build inventory synchronisation systems that keep stock levels accurate across every channel and location in real time — ingesting stock movements from every source, propagating reductions and replenishments to every destination, and giving operations teams the visibility and control to manage inventory across the full complexity of how their business actually operates.
The Synchronisation Problem in Practice
Inventory synchronisation sounds straightforward until you encounter the conditions that make it hard in practice:
Latency. A sale happens on Shopify. The stock reduction needs to reach Bol.com before another customer there buys the same last unit. How long does that take? If the synchronisation runs on a five-minute polling schedule, the answer is up to five minutes — during which the last unit can be oversold on every channel simultaneously. Real-time synchronisation driven by webhooks and event streams reduces that window to seconds.
Concurrent updates. Two sales happen simultaneously on two different channels for the same last unit. Both transactions succeed at the platform level before the stock reduction from either has propagated to the other. Without concurrency handling — optimistic locking, atomic stock reservation, or a centralised stock ledger that processes updates sequentially — both sales confirm and one cannot be fulfilled.
Multi-location stock. A business with multiple warehouses, fulfilment partners, or retail locations has stock that is available from different sources. The question is not just how much stock exists in total but how much is available from which location for which channel — and the routing logic that determines which location fulfils which order.
Buffer stock. Selling down to the last unit on every channel simultaneously is high-risk. A synchronisation system that maintains configurable buffer levels — holding back a defined quantity from display to provide a safety margin against concurrent purchases and synchronisation latency — reduces oversell risk without requiring manual management of channel-specific stock allocations.
Supplier and purchase order stock. Stock that is on order from a supplier but not yet received affects what can be displayed as available for pre-order or future delivery. Integrating purchase order data into the stock picture requires connectivity to the ERP or purchasing system that tracks inbound stock.
Bundled and composite products. Products that are assembled from components — a bundle containing three individual SKUs, a product that consumes raw materials from stock — require the synchronisation system to update component stock when bundle sales occur, and to calculate available bundle quantity from component availability.
How We Build Synchronisation Systems
Event-driven architecture. Stock synchronisation that runs on a polling schedule — checking for changes every N minutes — introduces a latency window during which overselling can occur. Event-driven synchronisation eliminates that window: when a sale occurs, a webhook fires immediately, the stock reduction is processed as the event is received, and the updated stock level is propagated to all other channels before the next sale can occur.
We build synchronisation systems around webhook event streams from each connected platform — Shopify order webhooks, Bol.com order notifications, WooCommerce webhooks — with the idempotency handling and ordering logic that reliable webhook processing requires. For platforms that do not support webhooks, we implement efficient polling with change detection that minimises latency while managing API rate limit consumption.
Centralised stock ledger. Rather than attempting to keep every platform's stock level in sync with every other platform's stock level directly — a mesh of point-to-point synchronisations that grows quadratically with the number of channels — we maintain a centralised stock ledger that is the single source of truth for available quantities. Each platform's stock level is derived from the ledger. Stock movements — sales, returns, receipts, adjustments — are recorded against the ledger, and the resulting stock levels are pushed to each platform.
The centralised ledger provides atomicity: stock reservation is a ledger operation, and concurrent reservations are serialised at the ledger level rather than racing across multiple platform API calls.
Per-channel stock allocation. Different channels may have different stock allocations — a business that wants to protect stock for B2B customers while selling surplus through marketplace channels, or that wants to maintain separate physical and digital inventory pools. Per-channel allocation logic in the synchronisation system applies these rules automatically rather than requiring manual management of channel-specific listings.
Real-time propagation. When the centralised ledger updates, the new stock level is pushed to all connected platforms immediately — not queued behind other updates, not batched with other platforms' updates. Propagation is parallel across platforms so that a stock update reaches Shopify and Bol.com simultaneously rather than sequentially.
Platform Integrations
Shopify. Stock level updates via the Inventory API, with location-aware inventory management for multi-location Shopify setups. Order webhook processing for real-time stock reduction on sale. Inventory adjustment API for bulk corrections and replenishment recording.
WooCommerce. Stock management via the WooCommerce REST API, with support for variable products and per-variation stock tracking. Order webhook processing for real-time reduction. Bulk stock update endpoints for efficient replenishment synchronisation.
Bol.com. Offer stock updates via the Bol.com Retailer API, with the polling-based order retrieval that Bol.com's API model requires. Stock update rate limit management to stay within Bol.com's API constraints while keeping stock levels current.
Amazon Seller. Inventory quantity updates via the Amazon Selling Partner API. Order notification processing for stock reduction. FBA inventory tracking for sellers using Amazon fulfilment alongside self-fulfilment.
ERP and accounting systems. Stock movement data from Exact Online, AFAS, and SAP as the authoritative source for stock receipts, adjustments, and write-offs. Purchase order data for incoming stock that affects available-to-promise quantities.
Warehouse management systems. Direct integration with warehouse systems for businesses where the warehouse system is the authoritative source of physical stock levels — with the synchronisation running from warehouse outward to sales channels rather than from sales channels inward.
Custom internal systems. For businesses managing stock through internal databases or custom inventory management tools, direct database integration or REST API connectivity feeds stock movements into the synchronisation system.
Visibility and Operations
A synchronisation system that runs invisibly is a synchronisation system that cannot be diagnosed when something goes wrong. We build operational visibility into every synchronisation system:
Stock level dashboard. A real-time view of stock levels across all channels and locations — showing current quantities, recent movements, and discrepancies where channel stock levels have diverged from the ledger. Operations teams can see the current state of inventory across the full channel landscape without querying each platform individually.
Movement history and audit log. Every stock movement recorded in the ledger — sale, return, receipt, adjustment, correction — is logged with its source, its timestamp, and the resulting stock level. When a discrepancy needs to be investigated, the movement history shows exactly what happened and when.
Discrepancy detection and alerting. When the stock level on a platform diverges from the ledger value — due to a direct edit on the platform, a synchronisation failure, or a race condition that was not handled correctly — the system detects the discrepancy and alerts operations teams. Discrepancies are surfaced immediately rather than discovered during a manual stock count.
Synchronisation health monitoring. API connectivity to each platform, webhook delivery health, and queue processing depth are monitored continuously. A platform connection that has failed, a webhook that has stopped delivering, or a processing queue that is falling behind are surfaced before they cause stock level inaccuracy.
Technologies Used
- Rust — high-throughput stock event processing, real-time propagation, concurrent update handling
- C# — ERP and enterprise system integration, complex business logic for allocation and reservation
- SQL (PostgreSQL, MySQL) — centralised stock ledger, movement history, audit logging
- Redis — stock reservation locks, event queuing, processing state
- REST / Webhooks — platform connectivity for all integrated sales channels and source systems
- Shopify API — Shopify inventory management and order processing
- WooCommerce API — WooCommerce stock management
- Bol.com Retailer API — Bol.com offer and order management
- Amazon Selling Partner API — Amazon inventory and order integration
- Exact Online / AFAS / SAP — ERP stock movement integration
Getting Inventory Synchronisation Right
Inventory synchronisation failures are silent until they are not — and when they surface, they surface as customer complaints, fulfilment failures, and the operational cost of manually resolving the discrepancies that accumulated while the synchronisation was broken. The cost of building it correctly is a fraction of the recurring cost of managing it incorrectly.
The starting point for every synchronisation project is a complete map of the stock landscape — every channel that stock is sold through, every location that stock is held in, every system that records stock movements, and every integration point where the synchronisation needs to connect. From this we design the synchronisation architecture appropriate to the complexity of the operation and the latency requirements of the channels involved.