Periodic, multi-objective fulfilment network design for cross-border commerce: a design

1Context and motivation

A delivery promise shown on a product page is bounded by decisions made months or years earlier: which fulfilment nodes exist, where they are, which customers each one serves, and how goods cross borders between them. Those decisions matter commercially. When a US apparel retailer opened a new distribution centre that made online deliveries to western states faster without announcement, online sales rose by 1.45% on average per business day of delivery time removed, from a baseline of seven business days, with a positive spillover to its physical stores¹. When Alibaba unexpectedly removed SF Express, a high-quality delivery option, for 42 hours in June 2017, sales, measured on 129,448 representative stock-keeping units, fell by 14.56% during the clash². Both are single-setting estimates, but they show that delivery speed and logistics quality are demand-side variables, not only cost lines.

Network design is still often run as an occasional project: collect demand and costs, solve a location model for minimum cost, build, and operate until the next study. Between studies, demand moves between regions, carriers change rates, routes become risky, and the network drifts from the design it was built for.

This paper describes the design we propose for a network planning service that runs location and flow models on a schedule with several objectives, and feeds its results to the services that route orders and replenish stock. An earlier version of this paper reported simulated comparisons of static and adaptive designs, and regional findings, that we cannot show; they are removed.

2Foundations

Facility location has a long history in operations research. The median problem, placing a facility to minimise total weighted distance to demand points, is among the earliest location formulations: Hakimi generalised the median of a graph to weighted graphs and showed that the optimum location of a switching centre in a communication network is always at a vertex³. Distribution system design generalises this to several commodities, plants, candidate warehouse sites and customer zones as a mixed integer linear program; Geoffrion and Graves solved such a problem for a major food firm with 17 commodity classes, 14 plants, 45 candidate distribution centre sites and 121 customer zones using Benders decomposition⁴. A textbook treatment of these models and their algorithms is given by Daskin⁵. Hub location, where flows are consolidated at hubs between origins and destinations, grew into a distinct research area after two seminal 1986 publications⁶; we treat cross-border consolidation as a hub problem.

Facilities operate for years or decades, during which costs, demands and travel times may change substantially, and many approaches to optimisation under uncertainty have been applied to location⁷. Two of them shape our design. Stochastic programming optimises the expected outcome over a set of scenarios, with first-stage decisions (where to build) taken before uncertainty resolves and second-stage decisions (how to route flow) taken after⁸. Robust optimisation instead accepts a solution that is somewhat worse at nominal values in exchange for one that stays feasible when data change, with an adjustable level of conservatism⁹.

Classical location models also assume that chosen facilities always operate. Reliability models add the expected cost of serving customers from more distant facilities when one fails; trade-off curves between normal operating cost and expected failure cost often show substantial reliability gains for small increases in operating cost¹⁰. Compact mixed integer formulations with site-dependent failure probabilities, and continuum approximations for large instances, make these models usable at scale¹¹.

Two further results connect network shape to inventory and capacity. Consolidating stock for several locations lowers expected holding and shortage costs by an amount that depends on how correlated their demands are¹², which is the inventory argument for fewer, larger nodes. Little's law, L = λW, ties the average number of units in a system to the arrival rate and the average time spent in it¹³, which lets a design convert node throughput and dwell time into the stock and space a node must hold.

3Design principles

• Re-evaluate on a schedule. The network model runs quarterly and when a trigger fires (a sustained shift in regional demand, a new lane or market, a change in a major cost).
• Several objectives, visible weights. Cost to serve, delivery time by region, expected cost under node failure and, optionally, an emissions proxy per lane are separate terms.
• Uncertainty is modelled, not averaged away. Demand growth and costs enter as scenarios or uncertainty sets.
• Design and operation share data. The model is calibrated on lead times and costs observed by order routing, and its output becomes routing and replenishment configuration.
• People decide; the model informs. The service produces options and trade-off curves. Opening or closing a node is a business decision.

4Architecture

4.1Inputs

Order history by item group, destination region and channel; growth scenarios by region; fixed and variable costs per candidate node; line-haul, last-mile and duty costs per lane; observed transit-time distributions; node capacity; service targets by region; and, where they apply, cross-border constraints. In a multi-merchant setting, demand is aggregated across merchants who use shared nodes, so the model plans for the platform's combined flow rather than one firm's.

4.2Scenario generator

Produces demand and cost scenarios: a base case, high and low growth by region, a new market, and price shocks on major lanes. Each scenario has a weight for the stochastic model and bounds for the robust model.

4.3Optimisation core

A mixed integer program chooses which candidate nodes are open and their role (full fulfilment node, cross-border hub, returns node), assigns destination regions to primary and backup nodes, and routes flow between nodes. The base is a multi-commodity facility location formulation^{4, 5} with hub consolidation for cross-border flow⁶. Uncertainty enters in one of two modes, selected by the analyst: two-stage stochastic, minimising expected cost over the scenarios⁸, or robust with a conservatism budget⁹.

4.4Reliability term

Each candidate node has a failure probability estimated from its history and region. The objective includes the expected cost of serving each region from its backup node when the primary fails^{10, 11}. The output is a trade-off curve, not a single design, so that planners can see how much reliability each increment of operating cost buys.

4.5Capacity and inventory check

For each candidate design, node throughput and planned dwell times give the stock and work in progress each node must hold¹³, and the pooling effect of the design is estimated from measured demand correlations¹². Designs that need more capacity than a node has are rejected before they are scored.

4.6Simulation check

The top candidates are replayed against logged orders with stochastic transit times and node outages, to check that the static model's averages hold up under day-to-day variation.

4.7Feedback to operations

The chosen design becomes configuration for the order routing service (primary and backup nodes per region, cross-border hub routes) and for replenishment (which nodes stock which item groups). Observed transit times and costs flow back to calibrate the next run.

Component	Problem it addresses	Evidence
Multi-commodity location and flow model	Choosing node locations and roles together	3, 4, 5
Hub consolidation for cross-border flow	Many small cross-border flows at high unit cost	6
Stochastic or robust treatment of inputs	Long-lived decisions on uncertain demand and costs	7, 8, 9
Reliability term with backup assignment	Designs that assume nodes never fail	10, 11
Pooling estimate from measured correlation	Over- or under-stating the inventory value of fewer nodes	12
Throughput and dwell to stock and space	Designs that exceed node capacity	13
Delivery time as an objective, not a constraint only	Cost-only designs that slow delivery	1, 2

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

5A worked model of the reliability trade-off

Table 2 compares two hypothetical designs for one region. Design A serves the region from one node at a normal cost of 100 per period; if that node fails, the region is served from a distant node at 300. Design B uses two nearer nodes at a combined normal cost of 108; if one fails, the other carries the region at 130; if both fail, the distant node serves it at 300. Failures are independent, with the same probability p per period at every node.

Failure probability p (input)	Design A expected cost (computed)	Design B expected cost (computed)	Lower expected cost
0.02	0.98 x 100 + 0.02 x 300 = 104.00	0.9604 x 108 + 0.0392 x 130 + 0.0004 x 300 = 108.94	A
0.05	0.95 x 100 + 0.05 x 300 = 110.00	0.9025 x 108 + 0.0950 x 130 + 0.0025 x 300 = 110.57	A, narrowly
0.10	0.90 x 100 + 0.10 x 300 = 120.00	0.8100 x 108 + 0.1800 x 130 + 0.0100 x 300 = 113.88	B

Source: Worked model; inputs in the table.

At low failure probability the cheaper single node wins on expected cost. Somewhat above p = 0.05 the ranking flips, and at p = 0.10 the two-node design is cheaper by about 6 per period. Expected cost also hides variance: design A's cost in a failure period triples, design B's rises by about a fifth, which is why the service reports the full trade-off curve rather than only the expected value. In this example design B also places nodes nearer to customers, which the delivery-time objective would credit separately.

6Fairness, sustainability and data

Network design decides which regions get fast delivery. An optimiser that minimises total cost will tend to serve dense, high-volume regions first. The design states minimum delivery-time targets per region as constraints set by people, and reports what each costs; fairness constraints in allocation have a measurable efficiency cost, characterised tightly for proportional and max-min fairness¹⁴. An emissions proxy per lane can be added to the objective with its own weight, so that the trade-off between faster modes and lower emissions is visible rather than implicit. Merchant demand data used in the model is aggregated; no merchant sees another merchant's volumes.

7Evaluation protocol

Before any claim about cost or delivery time could be made, a deployment would need to: back-test the model by solving it on data available at an earlier date and comparing its recommended design with what the network then needed; compare modelled and observed transit times and costs per lane after each change; and, where a new node opens in one region only, estimate the effect on sales and delivery time with a difference-in-differences design against comparable regions, as in the cited delivery-speed study¹.

8Limitations

• No measurements. We have not measured the effect of this design. The sales effects quoted are from other firms in other settings.
• Model inputs. Failure probabilities, growth scenarios and cost forecasts are estimates; a precise optimiser on uncertain inputs can give a false sense of precision.
• Regional simplification. The earlier version described network shapes by continent without a source. Those claims are cut; real designs need country and lane data.
• Regulation and tax. Customs, tax and licensing constraints are entered as rules; the model does not interpret law.
• Independence. Table 2 assumes independent failures; a regional event can take out nearby nodes together.
• Decision rights. The service recommends; it does not account for lease terms, labour markets or the time it takes to open a node.

9Conclusion

We have described a network planning service that re-runs location and flow models on a schedule, with cost, delivery time, reliability and robustness as explicit objectives, and passes its result to order routing and replenishment. Each part rests on published work summarised in Table 1, and Table 2 shows how the preferred design depends on failure probability. The next step is a back-test on historical data, reported with its method.