advanced 2 min answer

A logistics platform is replacing its core routing system. Should it run the old and new systems in parallel, and for how long?

delhiveryparallel-runverificationcutovercost
Show the full answer Hide the answer

When a parallel run is worth it

When the new system's correctness cannot be established any other way and the cost of being wrong is high. For a routing system that determines physical movement, an error is a real cost — a vehicle sent to the wrong place — and it is not recoverable by a retry.

The parallel run produces the only evidence that matters: the two systems, given the same real inputs, produce equivalent outputs.

How to run it well

  • Shadow rather than duplicate. The new system receives the same inputs and produces outputs that are compared and discarded, not acted on. Actually executing both is rarely feasible and is the version teams imagine when they reject the idea as too expensive.
  • Automate the comparison and classify differences. Manual comparison does not scale past the first week and stops happening.
  • Expect and triage differences. Most will be the new system being right, or a legitimate improvement, or a timing artefact. The purpose is to explain every difference, not to reach zero.
  • Define the exit criterion in advance: a period with no unexplained differences in a defined category. A parallel run with no exit criterion runs forever, which is the common failure.
  • Run it over a full business cycle, since a week does not include month-end, a peak, a holiday, or the weather event that exposes the difference.

What it costs

Compute for a second system, engineering to build the comparison, and the ongoing effort of triage — which is the largest and least anticipated cost. Teams size the infrastructure and underestimate the human time by an order of magnitude.

When to skip it

When the operation is reversible and the blast radius is small, in which case a progressive rollout with a fast rollback gives most of the assurance for a fraction of the cost. A shadow comparison is for the cases where you cannot simply try it on 1% of traffic and see.

Traffic shadowing without a full parallel system: replay production requests against the new implementation in a test environment and diff. It lacks live data and downstream effects, so it is weaker evidence — but it is available much earlier and finds most of the same divergences.