Orchestrating order assignment and inventory moves across a multi-node fulfilment network: a design

1Context and motivation

A retailer that sells online from several fulfilment nodes makes decisions that a single store never faces. In online retail the retailer, not the customer, decides where each item ships from, by which shipping method, and whether a multi-item order is broken into several shipments¹. The same retailer also decides where to hold stock and when to move it between nodes.

These decisions interact. Shipping an order from the nearest node is cheap today, but it may leave that node short for orders that arrive tomorrow, which then ship from further away at higher cost. Any assignment made the moment an order arrives is myopic in this sense, because it cannot account for later orders or for replenishment that has not yet happened². Rules such as "ship from the nearest node that has stock" or "replenish when stock falls below a threshold" ignore that coupling.

Enterprise resource planning, warehouse management and transport management systems each handle part of the problem, on their own data and their own schedule. What is missing in many setups is a layer that sees the network as a whole and makes order-level and inventory-level decisions with the same view of demand, stock, cost and delivery risk. This paper describes the design we propose for that layer. We describe what it decides, what it reads, and why each part is built the way it is. We do not report its effect on cost or service, because we have not measured it; an earlier version of this paper described simulated comparisons that we cannot show, and they are removed.

2Scope

The orchestration service makes decisions on three horizons.

• Order level, in seconds. For each order: the fulfilling node or nodes, the carrier and service level, the promised delivery date, and whether to split a multi-item order.
• Inventory level, in hours to days. Transfers between nodes, the split of inbound stock across nodes, and temporary changes to replenishment targets.
• Network level, in weeks to months. Signals for capacity and network planning, such as nodes that are persistently short or persistently overstocked. Network redesign itself is out of scope here.

Vehicle routing for the last mile, warehouse task scheduling and carrier rate negotiation are also out of scope. The service consumes their outputs (for example, carrier cut-off times and rates) but does not make those decisions.

3Design principles

• Price the future, not only the present. An order-level decision includes an estimate of the future cost of consuming the stock it uses, not just the immediate shipping cost¹.
• Revisit decisions while they are still cheap to change. Assignments that have not yet been released to a warehouse can be re-evaluated in batch with the benefit of later information².
• Forecast distributions, not points. Both demand and delivery time are uncertain; decisions that trade off risk need the shape of that uncertainty.
• Make objectives explicit. Cost, promise reliability, stock-out risk and, where a merchant chooses it, an emissions proxy are separate terms with visible weights, not hidden inside safety factors.
• Fast path and slow path are separate. The order-level decision has a latency budget; inventory moves and re-evaluation run as batch jobs that update the inputs the fast path reads.
• People keep the policies that move value between parties. Changes to how scarce stock is allocated across merchants or regions are approved by an operator.

4Architecture

4.1Inputs and state

The service maintains a current view of on-hand, reserved, in-transit and on-order stock per item per node; node and carrier capacity; cost per lane (picking, line haul, last mile, duties, returns); carrier cut-off times; and service commitments by region. It also reads the order stream and leading demand signals such as basket additions, broken down by item, region and channel. Region-specific rules (which carriers serve which postcodes, which lanes cross a customs border) are configuration, not code.

4.2Demand forecasting

Demand is forecast per item, region and channel as a distribution over several horizons. Global models trained across many related series can produce probabilistic forecasts for large catalogues, which retail inventory decisions need³. The same forecast feeds the order-level future-cost estimate and the rebalancing job, so the two do not argue from different numbers.

4.3Delivery-time models

For each node, carrier and destination, the service predicts the distribution of delivery time rather than a single estimate. Distributional forecasts with a cost-sensitive rule for choosing the promised day have been developed for online retail delivery promising, and the authors prove the rule optimal under certain cost structures⁴. The promise matters beyond the single order: in archival data from an online retailer, a fulfilment delay was followed by lower order frequency and smaller orders from previously loyal customers⁵.

4.4Order assignment

For each order the service scores candidate nodes and carriers. The score is the immediate cost (pick, pack, ship), plus an estimate of the future cost of using that node's stock, plus a penalty proportional to the predicted probability of missing the promise. The future-cost term is the central idea. In the heuristic of Acimovic and Graves, it is estimated from the dual values of a transportation linear program; on an industrial partner's data the heuristic captured 36% of the gap to a clairvoyant benchmark, an outbound shipping cost reduction on the order of 1%, without lower service levels or higher holding cost¹. We adopt the structure, not the number: what the future-cost term is worth in another network is something to measure.

Multi-item orders add a consolidation problem. If each item's node is chosen independently from a linear-programming solution, items of the same order scatter across nodes; correlated rounding across the items of one order consolidates shipments and performs close to optimal across a wide range of parameters in the authors' numerical experiments⁶. The service therefore assigns multi-item orders jointly.

4.5Re-evaluation

Orders that have been assigned but not released to a warehouse are re-evaluated in batch every few minutes. Periodic re-evaluation of real-time assignments, with heuristics that minimise the number of shipments, showed significant saving opportunities when tested on order data from a major online retailer². The batch window is a parameter: a longer window gives more information and less time to act.

4.6Inventory positioning and rebalancing

Rebalancing is treated as a multi-echelon inventory decision. When one installation is supplied by another, its effective lead time depends on stock at the upstream installation, not only on transit time⁷. Where to hold safety stock in a network can be optimised when each stage commits to a fixed service time towards its customers⁸, and consolidating demand from several locations lowers expected holding and penalty costs, by an amount that depends on how correlated their demands are⁹. The rebalancing job proposes a transfer when the expected cost of not moving the stock (lost sales or long-distance shipments) exceeds the cost of moving it, under the current demand forecast.

4.7Sequential decision layer

Using a unit now raises the risk of a stock-out later, so the decisions form a sequential problem under uncertainty, which is the setting of Markov decision processes¹⁰. Exact solution is intractable at network scale, and approximate dynamic programming offers ways to estimate value functions for large state spaces¹¹. Deep reinforcement learning has matched state-of-the-art heuristics on stationary lost-sales, dual-sourcing and multi-echelon inventory problems, but required demanding initial tuning and gives little structural policy insight¹². In our design a learned policy is optional: it is trained and compared offline against the heuristic policies above, and runs in production only if it passes the evaluation below.

4.8Integration

The service exposes an online endpoint for order-level decisions, called by the order management system, and a batch interface that writes transfer proposals and replenishment overrides to warehouse and planning systems. Every decision is logged with the forecast version, cost table version and policy version that produced it.

Component	Problem it addresses	Evidence
Future-cost term in order assignment	Myopic assignment depletes stock needed for later orders	1
Batch re-evaluation of unreleased orders	Assignments made before later orders arrive	2
Joint assignment of multi-item orders	Independent item choices split orders into extra shipments	6
Distributional delivery-time forecast and promise rule	Over- or under-promising delivery dates	4, 5
Probabilistic demand forecasts	Point forecasts hide the risk that drives stock decisions	3
Multi-echelon rebalancing	Upstream stock shapes downstream lead time; pooling changes cost	7, 8, 9
Offline-evaluated learned policy	Sequential effects of stock use under uncertainty	10, 11, 12

Source: our design, with the works cited in the table.

5A worked example of future-cost pricing

Table 2 shows, with invented inputs, how the future-cost term can reverse the choice a nearest-node rule would make. Node A is near the customer but holds its last unit; node B is further away and well stocked.

Quantity	Node A	Node B	Note
Immediate shipping cost	5.0	8.0	Input
Units on hand after this order	0	40	Input
Probability another local order arrives before replenishment	0.6	0.0	Input (from demand forecast)
Cost of serving that later order from the far node	12.0	n/a	Input
Cost of serving it from A if A still had stock	5.0	n/a	Input
Expected future cost of using this unit	0.6 x (12.0 - 5.0) = 4.2	0.0	Computed
Total score	9.2	8.0	Computed: immediate plus future

Source: Worked model; inputs in the table.

A nearest-node rule ships from A at 5.0. With the future-cost term, B scores lower (8.0 against 9.2) and the unit at A is kept for the order that is likely to follow. If the probability of a later local order were below 3 / 7, about 0.43, A would win again; the decision depends on the forecast, which is why the forecast and the assignment must share one source. The example ignores the promise penalty and assumes delivery from both nodes meets the promise.

6Information sharing, fairness and governance

Orders passed upstream are a distorted signal of demand: their variance can exceed that of sales and the distortion grows towards the supplier¹³. The service therefore shares its demand forecasts and stock positions with replenishment planning directly, rather than letting upstream planners infer demand from transfer requests.

When stock or capacity is scarce, the service decides who is served first. That is an allocation among parties, and any fairness rule has a cost in total efficiency; for proportional and max-min fairness that cost, the price of fairness, has a tight characterisation for a broad family of allocation problems¹⁴. Our design makes the rule explicit: a minimum service share per region and per merchant tier, set by an operator, with the cost of the constraint reported next to it.

Merchant demand and cost data are commercially sensitive. The service reads them under role-based access, does not expose one merchant's data to another, and keeps per-decision logs so that a merchant can be told why an order shipped from where it did.

7Evaluation protocol

Before any outcome claim, a deployment would need the following.

• Offline replay. Run the candidate policy on logged orders and stock, and compare outbound cost per unit, split-shipment rate, stock-out rate and promise accuracy against the incumbent rule.
• Pre-registered online test. Declare the target metric and guardrails (promise accuracy, cancellation rate, transfer volume) before launch¹⁵. Because orders share inventory, randomising individual orders would let treatment and control interfere through the same stock; we would randomise by region or by time period instead.
• Staged rollout. Shadow mode first, then a small share of regions, with automatic fallback to the nearest-node rule when a guardrail is breached.

8Limitations

• No measurements. We have not measured this design's effect on cost, promise accuracy or stock-outs. The figures quoted from the literature describe other networks.
• Future-cost estimates can be wrong. The future-cost term is only as good as the demand forecast and the cost model behind it; a biased forecast moves stock in the wrong direction with confidence.
• Interference in evaluation. Shared inventory makes clean experiments hard; region-level or time-based designs have fewer units and wider confidence intervals.
• Regional simplification. The earlier version described regional behaviour in broad continental groups. We removed those claims; real lanes differ by country and carrier, and the configuration layer has to be filled with local data.
• Learned policies. Results for deep reinforcement learning cited here are for stationary problems; commerce demand is not stationary.
• Fairness rules are choices. The design reports the cost of a fairness constraint; it does not say which constraint is right.

9Conclusion

We have described an orchestration service that assigns orders and moves stock with one view of demand, stock, cost and delivery risk. Its central mechanism, pricing the future cost of the stock each order consumes, and its supporting parts (re-evaluation, joint multi-item assignment, distributional forecasts, multi-echelon rebalancing) each rest on published work summarised in Table 1. The next step is the offline replay on logged orders, followed by a region-level test, reported with the method stated.