How we re-sequenced 4,000 stops in real time on Black Friday

Black Friday is the day every assumption in your routing model gets tested at once. Volume triples, drivers call in sick, and a depot you were counting on floods. For most last-mile platforms this is the day the "optimise" button quietly stops being pressed. This year, across every production tenant, 4klyft re-sequenced just over four thousand stops in real time and never dropped a parcel. Here is how.

The shape of the problem

Re-optimisation is not the same problem as planning. Planning happens overnight, with all the time in the world. Re-optimisation happens while a driver is holding the door handle of the van, and the answer has to be better than the plan they already have — or you have made things worse.

Decision one: freeze the past

The single most important rule in the engine is that completed stops are immutable. Once a proof-of-delivery signature is captured, that stop leaves the solver's search space entirely. This sounds obvious, but it is the difference between a re-optimisation that respects reality and one that tries to re-plan the morning you already drove.

function candidateStops(route: Route): Stop[] {
  // Completed + in-progress stops are frozen — the solver
  // never reconsiders proof-of-delivery it has already collected.
  return route.stops.filter(
    (s) => s.status === "pending" || s.status === "queued"
  );
}

Decision two: bound the search aggressively

A perfect solution you return in ten seconds is worthless. We run a metaheuristic with a hard wall-clock budget and return the best feasible solution found so far. In practice, on a 47-stop route, we are within two percent of optimal inside our 200ms window more than ninety percent of the time.

“The best route is the one the driver actually follows. A theoretically shorter route they ignore is not an optimisation — it is a rounding error.”

— Internal routing design doc, 2024

Decision three: degrade loudly

When a depot floods, the honest answer is sometimes "there is no good plan." Rather than silently returning the least-bad option, the engine surfaces the constraint that broke and hands the dispatcher a decision. Peak days are won by the humans; our job is to give them the sharpest possible picture, fast.

None of this is magic. It is three boring decisions applied without exception, on the one day of the year when exceptions are most tempting. That is usually where reliability actually comes from.