The routing decision for any given order depends on a simple question: which fulfillment node can pick, pack, and ship this order in time to meet the delivery promise? Answering that question correctly requires knowing, at the moment the order is placed, how much of the ordered item is actually available at each node and whether that node has the capacity to process a new order in the required timeframe.
Most routing systems are not designed to answer the question at that level of precision. They are designed to answer a simpler version: which node is geographically closest to the delivery address and has been configured to handle this product category? The geographic question is static and answerable from a routing table. The inventory and capacity question is dynamic and changes continuously throughout the day.
The gap between those two questions is where backorders are born.
How Inventory Signals Get Out of Sync
A routing system that reads inventory from a WMS sync that runs every 15 minutes is working with data that is, on average, 7.5 minutes stale. During normal operations, 7.5 minutes of inventory latency is usually fine. A fulfillment center with 200 units of a high-velocity item will not deplete meaningfully in 7.5 minutes under normal order volume.
The problem appears in two specific scenarios. The first is a flash sale or promotional event where order velocity spikes sharply and a high-demand item depletes at a rate much faster than normal. In this scenario, the 15-minute sync means the routing system can direct 40 or 50 orders to a node against inventory that was already exhausted before those orders were assigned. Each of those orders becomes a backorder exception that requires manual resolution.
The second scenario is more subtle: slow-depletion items at low-inventory nodes. A fulfillment center with 3 units of a SKU, operating at normal order velocity, might sell through those 3 units over the course of a morning. The routing system, checking inventory every 15 minutes, correctly sees 3 units in the first check, then sees 0 units in the next check, but in between has potentially directed 5 or 6 orders to that node assuming those 3 units would still be available.
The latency that is acceptable for a node with 500 units is not acceptable for a node with 3 units. This is the fundamental problem with fixed-interval WMS syncs: they do not adapt to the inventory sensitivity of the current routing context.
Event-Driven Inventory Updates
The architectural response to inventory sync latency is to move from polling-based inventory reads to event-driven inventory updates. Rather than the routing layer asking the WMS for current inventory on a schedule, the WMS publishes an event every time inventory changes, and the routing layer maintains a real-time inventory state by consuming those events.
This eliminates most of the sync latency, replacing a worst-case 15-minute lag with a lag measured in seconds, bounded by the latency of the event pipeline. The tradeoff is architectural complexity: the routing layer now needs to maintain a local inventory state derived from a stream of events, rather than reading directly from the WMS. The local state can diverge from the WMS state if events are delayed, lost, or processed out of order.
Event ordering is a real concern in high-volume operations. If the events representing "received 50 units" and "shipped 3 units" arrive out of order, the routing layer's local inventory state will be temporarily wrong. An event-driven inventory system needs to handle out-of-order delivery, duplicate events, and periodic reconciliation against the WMS source of truth to ensure the routing layer's state does not permanently diverge.
These are solvable engineering problems, but they are problems that need to be solved explicitly. A system that adopts event-driven inventory updates without implementing reconciliation and ordering guarantees trades one set of reliability risks for another.
Reserve Quantity and the Oversell Window
Even with low-latency inventory updates, there is a window between when an order is placed and when the inventory reservation is confirmed in the WMS. During high-concurrency periods, multiple orders can be placed simultaneously against the same inventory. The routing system needs a reservation mechanism that prevents concurrent orders from being assigned against the same units.
The standard approach is a soft reservation at the routing layer: when the routing system assigns an order to a node, it immediately decrements a local available-to-promise quantity, before the WMS has confirmed the reservation. If the WMS reservation subsequently fails because the inventory was depleted by a concurrent order, the routing system needs to handle the failure by either re-routing to an alternative node or escalating the order to manual review.
The failure rate of WMS reservation conflicts is a function of concurrency: how many orders are being processed simultaneously against the same inventory. At normal order volumes, conflict rates are low and the occasional reservation failure is a minor operational issue. During flash sales, conflict rates can spike significantly. A routing system that is not designed to handle reservation failures gracefully will produce a large batch of manual exception orders at exactly the moment when operations capacity is most constrained.
Multi-Node Routing and the Total Available Quantity
For an order that can be fulfilled from multiple nodes, the routing decision requires knowing the available quantity at each candidate node, not just whether the preferred node has inventory. A routing system that checks only the first-preference node and escalates to a fallback only after a failure discovers no inventory has already committed to the first-preference routing decision. Changing course after a reservation failure costs time.
A routing system with full visibility into the available inventory at all candidate nodes can make the routing decision more intelligently at the outset: if the preferred node has only 2 units left and the order quantity is 1, and an alternative node has 80 units, the routing decision should factor in the inventory position, not just the geographic preference. The preferred node's remaining inventory should be preserved for orders where it is the only viable option.
This kind of inventory-aware routing requires a routing layer that can see the current available quantity at all nodes in real time, not just a binary available/unavailable flag. The investment in lower-latency inventory signals pays additional dividends when the routing logic can use inventory depth, not just availability, as a routing input.
What Real-Time Inventory Visibility Does Not Solve
We want to be clear about what real-time inventory signals address and what they do not. Better inventory visibility in the routing layer reduces backorder incidents caused by assigning orders against depleted inventory. It does not solve backorders caused by genuine stock-outs: the item being ordered is simply not available anywhere in the network. It does not solve the supplier relationship and replenishment planning problems that lead to stock-outs in the first place.
Real-time inventory visibility is about fulfillment execution: routing orders correctly given whatever inventory state exists. It is not a substitute for inventory planning and replenishment strategy. The teams that get the most value from better routing signals are those who have already stabilized their inventory planning well enough that genuine network-wide stock-outs are relatively rare. When the problem is mostly routing correctness rather than total inventory shortage, better signals fix it. When the problem is total inventory shortage, better routing visibility will mostly surface that problem faster, not solve it.
For most retailers, both problems exist in parallel. The routing problem and the replenishment problem look similar on the surface, because both produce backorder exceptions. Separating them requires measuring the fraction of exceptions where inventory existed somewhere in the network but was routed incorrectly, versus the fraction where inventory simply did not exist. That decomposition usually reveals that the routing-attributable share is larger than expected, which is where better inventory signals help most.