Exception Path Frequency

A logistics or fulfilment system will record deliveries that did not happen, stock that is not on the shelf, packages loaded onto the wrong vehicle, and addresses that do not exist. None of these is a software defect and all of them will continue at some rate regardless of how good the software is.

The exception path's frequency is therefore a business metric, and the correct engineering response is to make the path efficient rather than to attempt to reduce the rate to zero.

Why the framing matters

Treating exceptions as defects produces two failures: effort spent trying to eliminate something that cannot be eliminated, and an exception path that is under-designed because it was assumed to be rare — handled by whoever is available rather than by a process, which is where the cost accumulates.

Implementation patterns

• Exception paths with defined terminal states, expressed as business outcomes rather than errors — damaged, lost, refused, returned, undeliverable.
• An exception queue with an owner and a resolution clock, since physical exceptions are continuous and normal, not incidents.
• The physical action treated as authoritative, with the interface allowing an operator to correct the system — with an audit trail rather than a silent overwrite, since a correction is itself a business event.
• Reconciliation against physical counts, because no consistency model addresses a mis-pick.
• Safety stock and buffers, converting an unpredictable physical failure into a predictable cost.
• The rate tracked and segmented — by location, by partner, by product category — since a rising rate in one segment is an operational signal that nothing else surfaces.

The design rule that follows

Order the irreversible steps last. Every step moved later is a compensation you may never need to run — and when a compensation genuinely cannot exist, such as a package already collected, move the step later or gate it rather than writing an action that lies about being able to undo.

Industry example

Logistics platforms such as Porter and Delhivery run at a scale where the exception rate, however small in percentage terms, is a large absolute volume — and it is where a substantial proportion of operational cost and customer dissatisfaction lives.

The platforms that handle it well treat the exception path as a first-class product surface with its own design, its own metrics and its own owner, rather than as an error handler.

Failure scenarios

• No exception states, so real outcomes are recorded as errors or not at all.
• The exception queue unowned, accumulating.
• Corrections applied without an audit trail, so a discrepancy cannot be investigated.
• The rate untracked, so a deteriorating partner or location is invisible.
• Compensating actions that cannot actually compensate, giving downstream systems false confidence.

Trade-offs

Designing a first-class exception path costs engineering effort on a flow that, by definition, is not the main one — and it competes with features on the successful path.

The counter is that the exception path is where the cost and the customer dissatisfaction concentrate, and that a business operating at scale in the physical world will spend more on exceptions than on any single feature. Measuring the rate is what makes that argument with evidence rather than as an assertion.

Interview question

"What proportion of your deliveries take an exception path, what does each one cost you, and who owns that number?"