Logistics and Supply Chain

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 seven areas underneath

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.

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.

flowchart TD
    A[Demand plan] --> B[Purchase order to supplier]
    B --> C[Advance ship notice]
    C --> D[Receiving and putaway]
    D --> E[Stock available to promise]
    E --> F[Customer order allocates it]
    F --> G[Pick, pack, manifest]
    G --> H[Line haul to depot]
    H --> I[Last mile delivery]

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.

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

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.

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 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.

stateDiagram-v2
    [*] --> Manifested
    Manifested --> InTransit
    InTransit --> OutForDelivery
    OutForDelivery --> Delivered
    OutForDelivery --> AttemptFailed
    AttemptFailed --> OutForDelivery
    AttemptFailed --> ReturnedToDepot
    ReturnedToDepot --> OutForDelivery
    ReturnedToDepot --> ReturnedToSender

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.

sequenceDiagram
    participant S as Shipper system
    participant V as Value added network
    participant C as Carrier system
    S->>V: Load tender
    V->>C: Load tender
    C-->>V: Functional acknowledgement
    C-->>V: Business acceptance
    V-->>S: Accepted
    C->>V: Status message, picked up
    V->>S: Status message

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.