How to Build Route Optimisation Systems That Scale Beyond Simple Distance

A delivery platform can produce a mathematically short route and still perform badly in production. The reason is that real dispatch systems must account for vehicle capacity, delivery windows, driver availability, service duration, priorities, and changing traffic conditions. Route Optimisation therefore needs to be treated as a constrained planning problem rather than a simple shortest-path calculation.

For teams building logistics, field-service, or last-mile platforms, the architecture matters as much as the solver. A useful starting point is understanding how route optimisation solutions work for fleet planning.

This article shows how to structure a route optimisation service using Python and Google OR-Tools, including constraint modeling, solver configuration, and production considerations.

Context and Setup

A production routing system typically contains four layers:

1. Order layer: deliveries, pickups, priorities, and service duration.
2. Fleet layer: vehicles, capacities, driver schedules, and depots.
3. Routing layer: distance and travel-time matrices.
4. Optimisation layer: constraints, objective functions, and solver configuration.

Google's OR-Tools documentation notes that vehicle routing problems become computationally difficult as the number of locations increases. For 20 locations, an exhaustive search of all possible tours would involve more than 2.4 quintillion route permutations. This is why practical systems use specialised optimisation techniques rather than brute-force enumeration.

For delivery applications, the model should normally include capacity and time-window constraints instead of optimising distance alone. OR-Tools supports both types directly.

Designing Route Optimisation as a Constraint Problem

Route Optimisation works best when business rules are expressed as explicit constraints and objectives.

Step 1: Define the Routing Model

Start by separating immutable input data from optimisation parameters.

A simplified model might contain:

from ortools.constraint_solver import pywrapcp
from ortools.constraint_solver import routing_enums_pb2

# Why: keep routing data independent from solver configuration.
data = {
    "distance_matrix": distance_matrix,
    "num_vehicles": 10,
    "depot": 0,
}

manager = pywrapcp.RoutingIndexManager(
    len(data["distance_matrix"]),
    data["num_vehicles"],
    data["depot"]
)

routing = pywrapcp.RoutingModel(manager)

This separation becomes important when the same optimisation engine needs to support different depots, fleet sizes, or planning horizons.

Step 2: Add Business Constraints

Distance should rarely be the only constraint.

For example, a capacity constraint can prevent the solver from assigning more demand to a vehicle than it can physically carry:

def demand_callback(from_index):
    # Why: convert the solver index into the business location index.
    node = manager.IndexToNode(from_index)
    return demands[node]

demand_index = routing.RegisterUnaryTransitCallback(demand_callback)

routing.AddDimensionWithVehicleCapacity(
    demand_index,
    0,                 # No extra capacity at route start.
    vehicle_capacities,
    True,              # Start every vehicle with zero load.
    "Capacity"
)

Google's reference implementation demonstrates the same modeling principle for capacity-constrained vehicle routing.

For delivery operations, time windows can then be added as another dimension. This allows the model to represent requirements such as "deliver between 10:00 and 12:00" rather than treating every stop as interchangeable.

Step 3: Control Solver Behaviour

Large routing problems should have explicit search limits.

OR-Tools supports time limits, solution limits, and local-search strategies. Its documentation identifies Guided Local Search as a commonly effective metaheuristic for vehicle routing.

This creates an important engineering trade-off:

Strategy	Advantage	Trade-off
Exact search	Can find optimal solutions	Can become impractical at scale
Greedy initial solution	Fast starting point	May produce weaker routes
Local search	Improves existing routes	Does not guarantee global optimum
Time-limited optimisation	Predictable API behaviour	Result may be near-optimal

For production systems, a time-bounded solver is often more useful than waiting indefinitely for mathematical optimality.

Real-World Application

In one of our logistics optimisation engagements at Oodles, the architectural challenge was to support route planning where delivery assignments depended on operational constraints rather than distance alone.

The recommended design separated order ingestion, geocoding, travel-time calculation, optimisation, and route execution into independent services. The optimisation engine received a normalised planning model containing stops, vehicle capacity, service duration, and scheduling constraints.

This architecture made it possible to replace or tune the optimisation engine without rewriting the order-management layer. It also allowed route recalculation to run asynchronously rather than blocking order creation.

For teams building similar systems, Oodles approaches route planning as a software architecture problem as well as an optimisation problem.

Four Production Mistakes to Avoid

1. Optimising distance only: A short route may violate capacity or customer time windows.

2. Calling the solver synchronously for every order: Frequent recalculation can create unnecessary compute pressure. Batch or event-driven optimisation is usually easier to control.

3. Using stale travel-time data: A mathematically good route can become operationally poor when travel conditions change.

4. Treating solver output as final: Dispatch systems need mechanisms for cancellations, failed deliveries, new orders, and vehicle availability changes.

Google's Route Optimisation API follows this broader model by accepting objectives and constraints such as travel efficiency, on-time arrival, vehicle capacity, time windows, and load balancing.

Key Takeaways

• Model routing as a constrained optimisation problem, not only a shortest-path calculation.
• Keep order, fleet, routing data, and optimisation logic separate.
• Use capacity, time windows, and service duration where they reflect real operational rules.
• Put explicit time limits around optimisation workloads.
• Design for re-optimisation because real-world routes change after planning.
• Measure route quality using operational KPIs such as distance, travel time, on-time delivery, vehicle utilisation, and solver latency.

Conclusion

Effective Optimisation balances mathematical solution quality with predictable system behaviour. The right architecture isolates the solver, models real constraints, and supports controlled recalculation as operational conditions change.

For technical teams evaluating routing architecture, discuss your Route Optimisation requirements with an engineering team and compare solver, API, and infrastructure options against your actual fleet constraints.

What is Route Optimisation?

Route Optimisation is the computational process of assigning vehicles and sequencing stops while satisfying operational constraints. Depending on the use case, the model may minimise distance, travel time, operating cost, or the number of vehicles while respecting capacity, driver schedules, and customer time windows.

Why is vehicle routing difficult to solve?

Vehicle routing becomes difficult because the number of possible route combinations grows rapidly as locations increase. Google notes that exhaustive enumeration becomes computationally impractical for larger problems, which is why routing systems use specialised algorithms and heuristic search strategies.

Should route planning optimise distance or time?

The objective should reflect the operational goal. Distance may be appropriate when fuel cost is dominant, while travel time may matter more for time-sensitive deliveries. Many systems combine objectives with constraints for capacity, service windows, driver schedules, and delivery priorities.

Can OR-Tools handle delivery time windows?

Yes. OR-Tools supports Vehicle Routing Problems with Time Windows, allowing each location to define an acceptable service interval. The solver can then search for routes that satisfy those windows while minimising the selected routing objective.

When should a business use a dedicated Route Optimisation service?

A dedicated Route Optimisation service becomes useful when routing involves multiple vehicles, capacity constraints, time windows, frequent re-planning, or complex assignment rules. Separating optimisation from core order processing also makes the platform easier to scale and maintain.