The systems that plan, move and account for physical goods from order to doorstep. Every hard problem here comes from the same place: the goods are real, they do not roll back, and what the software believes is only ever an approximation of where they are.
High demand19 min readSupply chain solution architect, Backend engineer (WMS/TMS/OMS), Integration engineer (EDI and carrier APIs), Optimisation engineer, Demand planner, Business analyst (logistics), WMS implementation consultantUpdated 2026-07-27
Assumes you know: Distributed systems basics, especially eventual consistency and idempotency, Relational modelling and SQL, Some exposure to message queues or event streams
Overview
What this area actually covers
This is the software that decides what goods should exist where, causes them to
be moved, and keeps an account of that movement good enough to bill, audit and
apologise for. In practice: order management, warehouse management,
transportation management, last-mile execution, track and trace, and the
planning layer that sets how much stock to hold and where.
The boundary people get wrong is with e-commerce, which owns catalogue, pricing
and checkout, everything up to the moment intent becomes a commitment. The two
areas meet at available to promise, the calculation of what you can credibly
offer given stock that is partly on a shelf, partly reserved for other orders
and partly on a ship.
Three things get wrongly bundled in: manufacturing execution, which is the shop
floor rather than the network; procurement, a commercial discipline that
happens to emit purchase orders; and mapping, mistaken for the routing problem
when it is only the distance matrix underneath it.
The section divides into seven subsections that follow the physical path of a
unit of stock, with planning and cross-border trade wrapped around it. The
division is worth taking seriously, because the systems are genuinely separate
products with separate vendors, and an engineer who has worked in a warehouse
system has learned almost nothing about routing.
Order to Delivery is the end-to-end view: the milestones a shipment passes,
who owns each hand-off, and the event model that reports progress to everyone
who asks. It exists first because it is the frame the other six fit into, and
because the most common failure in this domain is a hand-off nobody owns. Open
it for the milestone model, the boundaries between systems, and how a promise
made at checkout becomes a date somebody can hit.
Warehouse Operations covers what happens inside four walls: receiving goods
against an expected inbound, putting them away, choosing a picking strategy,
packing, and the warehouse management system that directs all of it. It is
separate because the constraints are physical and human — a pick path is walked
by a person, and a strategy that looks efficient on paper can double the
walking. Expect receiving and putaway, discrete versus batch versus zone
picking, packing and manifesting, and cycle counting.
Transportation & Routing is the movement between fixed points: building
loads, choosing carriers, rating freight against contracts, and the vehicle
routing problem that decides which vehicle visits which stops in which order.
It has its own area because the optimisation is real and because carrier
management is a commercial relationship with its own data. Read it for load
planning, routing as a heuristic problem under a wall-clock budget, and carrier
selection and rating.
Last Mile is the final leg, and it behaves unlike the rest: many small
drops, delivery promises and slots, a driver application used one-handed in the
rain, proof of delivery, and the failed attempt that costs more than the
successful one. It is separate because its economics are dominated by stop
density and its software by offline tolerance. Open it for slotting and
promises, driver applications, proof of delivery and failure handling.
Track & Trace is the observability layer over the physical network: scan
events, derived status, estimated arrival, exception detection, and the
customer communication that hangs off it. It warrants its own area because it
is an event-modelling problem disguised as a feed, and because the customer
sees its output directly. Expect event capture, out-of-order and late arrivals,
status derivation and exception rules.
Planning & Forecasting sets the inputs everything else consumes: how much
demand to expect, how much safety stock to hold, when to replenish, and how to
avoid amplifying variation up the chain. It is separate because its correctness
horizon is weeks or months rather than seconds, and because its input is a
prediction that will be wrong. Read it for forecasting, safety stock and
service levels, replenishment policies, and the bullwhip effect.
Trade & Customs covers moving goods across a border: classification,
documentation, duties and taxes, and the compliance screening that can stop a
shipment entirely. It is its own area because it introduces a party that can
refuse — a customs authority — and obligations that attach to the goods rather
than the order. Open it for classification codes, the documents that must
travel with a consignment, duty calculation, and denied-party screening.
Subsection
What it is for
Order to Delivery
The end-to-end flow and the milestones that report it
Warehouse Operations
Receiving, storing, picking and packing inside four walls
Transportation & Routing
Building loads and deciding who goes where in what order
Last Mile
The final leg, its promises, its drivers and its failures
Track & Trace
Scan events, derived status and exception handling
Planning & Forecasting
Deciding what stock should exist where, in advance
Trade & Customs
Getting goods across a border legally and priced correctly
Where it sits in a real business
Follow one unit of stock. A demand plan says a warehouse should hold some
quantity, a replenishment run turns that into a purchase order, and the
supplier sends an advance ship notice describing the inbound truck before it
arrives. Receiving compares what turned up against that notice, and the first
divergence of the day is recorded. Later a customer order allocates the stock,
a pick task sends a worker to its location, packing puts it into a carton with
its own identifier, and the carton is manifested onto a load.
Loading diagram…
The step to look at is the third. The advance ship notice is a promise about a
truck that has not arrived, and the gap between what it says and what is on the
pallet is the first reconciliation of the day, every day, in every warehouse in
the world.
It then moves in two economically different modes. Line haul is bulk movement
between fixed points, planned days ahead and optimised for consolidation. Last
mile is many small drops from a depot, dominated by stop count, time windows
and failed deliveries. A parcel cheap to move a thousand kilometres can be
expensive to move the last three.
Money lags the goods. Freight is rated against a contracted tariff, charges
accrue for things like waiting time and redelivery, and the carrier's invoice
arrives later disagreeing with your own figure. That reconciliation, plus damage
and shortage claims, is why the event history is evidence rather than telemetry.
Who is responsible for the goods right now
One idea underpins every cross-organisational conversation in this domain, and
newcomers routinely miss it: at every moment, exactly one party bears the risk
and the cost of the goods, and the point at which that transfers is contractual
rather than physical. In international trade the shorthand for it is the
Incoterms rules, a standardised set of terms published by the International
Chamber of Commerce that say who arranges carriage, who pays which costs and
where risk passes.
Term
Who arranges main carriage
Where risk passes, broadly
EXW
The buyer
At the seller's premises
FCA
The buyer, seller delivers to a carrier
On hand-over to the carrier
CIF
The seller, insured
On loading, at the port of shipment
DAP
The seller
On arrival at the named place
DDP
The seller, duties paid
On arrival, cleared for import
The engineering consequence is that "delivered" is not one event with one
meaning. Under one term a shipment is the buyer's problem the moment it leaves
a dock; under another it is the seller's until it is unloaded and cleared.
Systems that model a single delivery flag, with no notion of where
responsibility sat, cannot answer a damage claim.
The words that appear in the first meeting
Term
What it means in practice
ASN
Advance ship notice; what the sender says is on the way
SSCC
The identifier on a pallet or carton label
LPN
Licence plate; the handle a warehouse puts on a unit of handling
Putaway
Deciding and recording where received stock is stored
Wave
A batch of orders released to the floor together
Manifest
The list of parcels handed to a carrier, and the hand-off itself
Line haul
Bulk movement between fixed points
Stem time
The unproductive drive from depot to the first drop
Accessorial
A charge for something other than the move itself
Detention
A charge for keeping a vehicle waiting
Cross-dock
Moving goods from inbound to outbound without storing them
POD
Proof of delivery; a signature, a photograph or a code
Cycle count
Counting a subset of locations regularly rather than all at once
HS code
The classification that determines duty on a good
Two of these are worth pausing on. A wave is the unit of work release on a
warehouse floor, and how you construct waves determines walking distance,
packing bench congestion and whether the last van leaves on time — it is a
scheduling decision dressed as a batch job. And accessorial charges are
where freight invoices and internal estimates diverge, because they are the
costs incurred by things going slightly wrong.
Inside the four walls
Warehouse software is the part of this domain most often underestimated,
because from the outside it looks like inventory rows. What it really does is
direct human movement, and its quality is measured in walking.
The core decision is the picking strategy, and the trade-offs are concrete. In
discrete picking one worker picks one order from start to finish: simple to
reason about, easy to hold accountable, and wasteful when orders average two
lines because the walk dominates. In batch picking one worker picks the
same item for many orders at once, cutting travel enormously at the price of a
sortation step afterwards. In zone picking each worker owns an area and
orders pass between zones, which suits large sites but introduces hand-offs and
work-in-progress. Most real operations blend these by order profile, and the
software has to decide which strategy each order gets before it releases the
wave.
Two supporting ideas make those strategies work. Slotting decides where
each item is stored, putting fast movers near the packing benches and heavy
items low down, and it is re-run periodically because demand changes
seasonally. Cycle counting counts a rotating subset of locations during
normal operation instead of shutting the site for a full stocktake, which means
inventory accuracy is maintained continuously rather than corrected once a
year. Both are optimisation problems whose objective function is a person's
time, and both are places where a small software change produces a measurable
physical result within a day.
Who does this work
The builders are backend engineers on warehouse, transport and order management
systems, integration engineers who spend their week on partner onboarding and
message mapping, optimisation engineers owning the routing and slotting
solvers, and mobile engineers building scanner and driver applications. A
backend day skews towards data correctness: two systems disagree about a stock
figure, and the job is to decide which is right and why the divergence was
possible at all.
The operators and specifiers are warehouse managers, transport planners who
override the solver every morning for reasons it was never told, demand
planners, and control-tower analysts chasing exceptions. Beside them sit
implementation consultants and business analysts who configure packaged systems
rather than write code, and who usually understand what the business genuinely
does.
Role
Builds or operates
What they will tell you
WMS engineer
Builds
The pick path matters more than the query plan
Integration engineer
Builds
Every partner interprets the standard differently
Optimisation engineer
Builds
The best plan is the one drivers will run
Warehouse manager
Operates
The system is wrong about aisle fourteen again
Transport planner
Operates
I overrode the solver, and here is why
Control tower analyst
Operates
This shipment has been silent for nine hours
The transport planner is the role to understand if you want to be useful
quickly. Planners override optimiser output daily, and the reasons are almost
always real constraints the model was never told: a customer who will not
accept a delivery before ten, a driver who is the only one who can get into a
particular yard, a vehicle with a fault nobody logged. Treating those overrides
as data to be captured rather than as user error is how routing systems
eventually get trusted.
Demand, adoption and how that is changing
Demand is high for structural rather than fashionable reasons. Consumer
delivery expectations set over the last decade are now baseline, and meeting
them needs software where there was previously paper and a phone. A long tail
of shippers, third-party logistics providers and regional carriers is still
moving from spreadsheets and file-based EDI towards APIs, each migration a
multi-year programme. Labour cost pressure keeps pushing warehouses towards
automation, which relocates software work into orchestration between robotics
and the host system rather than removing it.
Two further pressures are worth naming. Supply chain disruption over recent
years turned visibility from a reporting nicety into a board-level requirement,
which funded a great deal of event-model and control-tower work. And
cross-border rules keep tightening — product-level data requirements,
origin declarations, screening obligations — which pushes classification and
compliance data into systems that previously carried a weight and a
destination.
What is commoditising deserves naming honestly. Geocoding, distance matrices
and raw ETA prediction are bought, not built; packaged warehouse products cover
straightforward operations well enough that writing one from scratch is rarely
justified. What has not commoditised is the layer encoding how a specific
operation works, because that is where every business genuinely differs.
What makes it hard
The physical world has no rollback. A failed transaction leaves no trace, but a
pallet moved to the wrong dock is in the wrong place, and the software can only
record that and compensate. Every workflow needs defined behaviour for the case
where the physical action succeeded and the system update did not, and for the
reverse.
So physical and system state diverge constantly, and reconciliation is a
continuous background process rather than an error path. Cycle counting exists
because inventory records drift even in a well-run warehouse. The question is
not whether divergence happens but how fast you detect it, which record is
authoritative, and whether the correction is auditable.
Routing is hard in the formal sense
Routing is hard in the complexity-theoretic sense: the vehicle routing problem
generalises the travelling salesman problem and is NP-hard, and real instances
add capacities, time windows, shift rules and vehicle access restrictions.
Nobody solves those to proven optimality at operational scale, so the
engineering is heuristics under a wall-clock budget: overnight planning may get
minutes, redispatching when a driver calls in sick gets seconds. The subtle
part is constraint modelling and objective weighting, because a mathematically
better plan that drivers refuse to run is worthless.
The distinction that matters in an interview is between hard and soft
constraints. A vehicle's capacity is hard: exceed it and the plan is invalid. A
customer's preferred window is usually soft: violate it and you incur a
penalty in the objective. Most disagreements between planners and solvers turn
out to be a constraint that the business treats as hard and the model treats as
soft, or the reverse.
Track and trace is an event model, not a feed
Track and trace looks like a feed and is really an event model. The framing
formalised in GS1's EPCIS standard is that every event answers four questions:
what object, when, where, and why in business terms. Scans arrive out of order,
duplicated, and hours late from a device that was offline, and no amount of
stream processing rescues a wrong model.
Event
What
Event time
Recorded at
Where
Why (business step)
1
Carton C-1
09:04
09:04
Depot A
departed
2
Carton C-1
11:20
14:55
Van 7
delivery attempted
3
Carton C-1
11:41
11:42
Van 7
delivered
Event 2 was captured offline and uploaded after event 3, so any consumer
treating arrival order as chronology concludes the parcel is undelivered and
notifies the customer wrongly. Event time and record time are separate fields
and both matter, and current status is derived from the ordered event set
rather than stored as a mutable column.
Loading diagram…
The cycle between AttemptFailed and OutForDelivery is where last-mile cost
concentrates, and it is also where customer communication goes wrong most
often, because a status derived from the latest received event rather than
the latest occurring event will flap between these states.
Identity compounds it: the tracked object changes as items are packed into
cartons and cartons onto pallets, so aggregation and disaggregation are
themselves events. A query for "where is my item" resolves through whatever
container it was last aggregated into, and if that association was never
recorded the item is untraceable even though the pallet is perfectly visible.
Planning is a bet on a wrong number
Planning is hard for a different reason. The input is a forecast, and forecasts
are wrong, so you are really building a system that behaves sensibly when the
prediction misses. Safety stock is the price of that, sized against lead-time
variability and a chosen service level, and the classic failure is the bullwhip
effect, where small demand variation amplifies as it propagates upstream
through each party's own buffering.
The bullwhip is worth understanding as a systems phenomenon rather than a
planning curiosity, because it is caused by rational local behaviour. Each
party in the chain observes its own orders rather than end demand, adds a
buffer for its own uncertainty, and batches orders for efficiency. Those three
reasonable decisions, composed, turn a small ripple at the shelf into a
violently oscillating order pattern at the factory. Sharing downstream demand
data upstream is the standard remedy, and it is an integration problem before
it is a mathematical one.
Integration is where schedules die
Electronic data interchange is load-bearing rather than legacy: X12 and
EDIFACT transaction sets for purchase orders, ship notices, status messages and
invoices carry a large share of trade, often over file transfer rather than
HTTP. The standards are permissive, so partners differ in optional segments and
interpretation, and onboarding is empirical work against real files.
Loading diagram…
The two acknowledgements in the middle are the point. A functional
acknowledgement says the file parsed; business acceptance says the carrier will
actually take the load. Treating the first as the second is one of the most
common integration defects in the domain, and it surfaces as a shipment that
everybody believes is booked and nobody has collected.
Carrier APIs share no shape between providers, so you own a canonical internal
model plus an adapter per partner, and acknowledgement semantics matter more
than payload: received, syntactically accepted and business-accepted are three
separate facts.
Offline is the normal case, not the failure case
Finally, this domain forces genuinely offline-tolerant mobile design rather
than the decorative kind. A scanner behind steel racking loses signal, a driver
in a rural area or an underground bay has none for stretches of a shift, and
the work cannot pause until the network returns. The device is therefore a
first-class writer, not a cache: identifiers are generated client-side so a
record exists before the server knows of it, every submission carries an
idempotency key because retries are certain, device event time is captured but
treated as suspect, and conflict resolution is a business rule, because two
contradictory delivery outcomes for one parcel is a question for operations
rather than for a timestamp comparison.
Taken together these difficulties have a single shape. Every one of them is a
gap between a record and a physical fact: the notice and the pallet, the count
and the shelf, the plan and the road, the scan and the parcel, the forecast and
the demand. The domain does not try to close those gaps, because they cannot be
closed. It measures them, bounds them, and makes the correction defensible.
Why study it
Distributed-systems reasoning pays off immediately and visibly here.
Idempotency, eventual consistency, event sourcing and reconciliation are
consequences of physics rather than architectural preferences, so you learn
them properly instead of as vocabulary. The knowledge is durable too: the
difference between allocated and available stock will mean the same thing in
ten years, unlike any framework.
There is also an unusually direct feedback loop. Most software teams infer
their impact from dashboards; here you can stand in the building and watch
whether the change you made means the last van leaves on time. That proximity
is either the best or the worst thing about the domain, and which one it is for
you is worth working out before you take the job.
Do not bother if you want the shortest route to a well-paid generic backend
role, because the domain premium is smaller than in payments or trading, or if
you dislike operational proximity, because when the system is wrong real trucks
wait and someone calls early. If your interest is machine learning research
rather than applied forecasting, the modelling work here is mostly unglamorous
time series and constraint solving.
Your first hour
Take one delivery you have received and reconstruct its history as an event
log, using the columns above and filling in event time and record time
separately for every row you can infer. Then break it deliberately: reorder two
rows to simulate an offline upload, duplicate one to simulate a retried
submission, and add one that contradicts an earlier row. For each, write in a
single sentence the rule that keeps the derived status correct anyway. The
artefact at the end is a one-page event model plus three reconciliation rules,
which beats a memorised glossary in an interview.
If you want a second exercise, work through the vehicle routing quickstart in
the OR-Tools guide with ten stops, then add time windows to two of them and
watch solution quality and runtime move. Then do the part that teaches the
domain rather than the library: add a constraint the solver cannot express
directly — say, that two particular stops must be served by the same vehicle
because they belong to one customer — and decide whether to model it as a
penalty, a pre-merge of the two stops, or a manual override. There is no clean
answer, and choosing between those three is what the job consists of.
What this is not
It is not e-commerce with a map attached. The storefront and the fulfilment
network are different systems with different failure modes, and conflating them
is the clearest tell that someone has not worked in the domain.
It is not a routing algorithms course. The optimisation is real, but most roles
spend far more time on integration, event modelling and reconciliation than on
solvers, and a candidate who can only discuss the travelling salesman problem
is answering a question nobody asked.
It is not a solved problem sitting inside packaged software. Enterprise
resource planning suites cover the standard shape of an operation, which is
precisely why the remaining work is the non-standard part, and that part does
not shrink as the packages improve. Nor is it the same discipline as
procurement or manufacturing, though one organisation chart often owns all
three.
Physical state and system state diverge by default, so the useful question is
never how to prevent divergence but how fast you detect it and how defensibly
you correct it.