When optimisation makes the system worse
A data science model can perform exactly as designed and still damage the wider system. Braess’s paradox, first identified in transport networks, offers a useful warning about what happens when local improvements produce poorer overall outcomes.
The paradox shows that adding capacity to a network does not always improve its performance. A new road, for example, can give individual drivers what appears to be a faster route. But when many people make the same rational choice, congestion can increase and everyone’s journey can take longer.
For data scientists, the lesson is about objective functions. A model can successfully optimise the metric it has been given while making the organisation less efficient, less resilient or less able to serve its customers.
That problem is not confined to transport. It appears whenever teams, algorithms or business units improve one part of a system without accounting for the effects elsewhere. One department reduces costs, another deals with rising complaints. One dashboard improves, while a less visible measure begins to deteriorate.
From each local viewpoint, the decisions may appear reasonable. Taken together, however, they can move the organisation towards a poorer overall outcome.
The last-mile delivery trade-off
Last-mile delivery provides a clear example.
Adding more orders to a route can reduce the cost per delivery. Vehicles carry more parcels, drivers spend less time underused and the fixed cost of each trip is spread across more customers.
At first, that is a genuine efficiency gain. A route serving 20 customers may be significantly more economical than one serving 10, particularly when the stops are close together.
But the benefit does not continue indefinitely.
As more deliveries are added, delays begin to accumulate. A driver encounters awkward parking, a locked entrance, a slow lift or a customer who takes longer than expected to answer the door. Each delay may be minor, but later stops inherit the time lost earlier in the route.
Eventually, cost per delivery may continue to fall while on-time performance begins to decline. That is where the optimisation trap appears: the metric being improved no longer represents the performance of the system as a whole.
Why the same model behaves differently
The point at which this trade-off appears will vary across delivery networks.
Dense urban routes behave differently from suburban or rural ones. Grocery deliveries with narrow time windows are less forgiving than parcels that can arrive at any point during the day. Apartment buildings introduce different delays from detached homes, while traffic patterns, parking restrictions and customer availability all affect route performance.
This means a batching rule that works well in one area may perform poorly in another. A model trained or calibrated on an urban delivery network cannot automatically be assumed to behave in the same way elsewhere.
The problem becomes more difficult when the operational data is incomplete. Cost and route duration may be measured accurately, while customer inconvenience, failed deliveries and pressure on support teams are recorded separately or not connected to the model at all.
A route may therefore appear efficient because some of its true costs are missing from the objective function.
When metrics pull in different directions
The organisational problem often begins with how performance is measured.
A logistics team may be responsible for cost per delivery. A customer service team may track complaints. Another part of the business may monitor refunds, reattempts or customer retention.
No one needs to make an obviously poor decision for the system to move in the wrong direction. Each team can act rationally according to its own targets while creating costs for another part of the organisation.
A model focused narrowly on route cost might recommend larger delivery batches because they improve vehicle utilisation. But if those batches also increase late arrivals, failed deliveries and customer contacts, the apparent saving may disappear once the wider costs are included.
This is why model evaluation cannot stop at the metric being optimised. Data scientists also need to examine downstream effects, unintended behaviours and the possibility that different parts of the system are responding to competing incentives.
Finding the divergence point
The useful question is not simply whether batching reduces cost. It is where the relationship between cost and service begins to separate.
Data can help identify:
- which route sizes produce the best balance between efficiency and punctuality
- which locations or delivery zones are most sensitive to additional stops
- whether delays become more likely at particular positions in a route
- how failed deliveries, complaints and reattempts affect the true cost of a batch
Simulation can be especially useful here. Rather than introducing a new batching rule across the entire network, organisations can test how it performs under different traffic levels, delivery windows, customer behaviours and route densities.
Lightweight digital-twin models can also help teams examine how changes in one part of the operation affect the rest of the system. This allows decision-makers to see where efficiency gains remain genuine and where they begin to create fragility.
The value of these models does not come from predicting every disruption perfectly. It comes from making trade-offs visible before they are embedded in day-to-day operations.
Optimising the whole system
Braess’s paradox does not suggest that additional capacity or greater efficiency is always harmful. Its deeper message is that network effects can produce outcomes that are difficult to predict by looking at individual components in isolation.
The same principle applies to data science. Models operate within systems made up of people, incentives, processes and competing goals. Improving one measure does not necessarily improve the organisation.
A route optimisation model should therefore be judged not only by whether it lowers cost per delivery, but by whether it supports reliable service, manageable workloads and sustainable customer relationships.
The cheapest route is not always the best route. The largest batch is not always the most efficient. And a model that reaches its target may still have missed the point.
The real advantage comes from seeing the system as a system, rather than as a collection of separate wins.
References
https://towardsdatascience.com/the-system-always-knows/
https://en.wikipedia.org/wiki/Braess%27s_paradox
https://www.networkpages.nl/traffic-congestion-iv-braess-paradox/