OSRM: The Reference Architecture for Lightning-Fast Routing & Logistics Without API Costs
Fabian Peter 5 Minuten Lesezeit

OSRM: The Reference Architecture for Lightning-Fast Routing & Logistics Without API Costs

For logistics companies, delivery services, and fleet managers, routing is the heart of the business. However, using the Google Maps Directions API for every route calculation or distance matrix burns capital significantly. API costs scale linearly with success, and sending live locations to US servers poses GDPR risks. OSRM (Open Source Routing Machine) ends this dependency. It is a C++-based high-performance routing engine that uses OpenStreetMap data. Operated in your own cluster, OSRM calculates thousands of routes per second at a fixed infrastructure price – absolutely sovereign and lightning fast.
osrm routing-engine openstreetmap logistik distance-matrices contraction-hierarchies in-memory-graph

TL;DR

For logistics companies, delivery services, and fleet managers, routing is the heart of the business. However, using the Google Maps Directions API for every route calculation or distance matrix burns capital significantly. API costs scale linearly with success, and sending live locations to US servers poses GDPR risks. OSRM (Open Source Routing Machine) ends this dependency. It is a C++-based high-performance routing engine that uses OpenStreetMap data. Operated in your own cluster, OSRM calculates thousands of routes per second at a fixed infrastructure price – absolutely sovereign and lightning fast.

1. The Architecture Principle: In-Memory Graphs & Contraction Hierarchies

Why is OSRM so much faster than traditional database-based pathfinding algorithms (like pgRouting)? The secret lies in preprocessing and architecture.

OSRM uses an algorithm called Contraction Hierarchies (CH) or alternatively Multi-Level Dijkstra (MLD).

  • The Preprocessing: OSRM takes raw OpenStreetMap data and preprocesses the road network in a multi-hour process. It creates “shortcuts” in the graph (e.g., “If you’re on the highway, don’t check every single exit if the destination is 500km away”).
  • In-Memory Speed: This optimized graph is completely loaded into the server’s RAM. The result? When your application requests a route, OSRM doesn’t have to search the hard drive. The response time for a route across Europe is in the millisecond range.

2. Core Feature: Distance Matrices & TSP (Traveling Salesperson)

Calculating a route from A to B is standard. The real challenge (and the biggest cost factor with Google) is complex logistics problems.

  • Distance Matrix: A delivery service has 50 drivers and 500 packages. To decide which driver takes which package, the system needs to know the travel times from every driver to every package. That’s a huge matrix. Google often calculates this per element. OSRM calculates large matrices asynchronously and for free.
  • TSP (Trip API): OSRM has a built-in “Traveling Salesperson” solver. You pass 20 addresses to the API endpoint, and OSRM automatically sorts them into the most efficient visit order – essential for route planning and waste collection.

3. Profiles: Car, Bicycle, Pedestrian (and Truck)

The definition of the “shortest route” depends on the vehicle. A one-way street is taboo for cars, irrelevant for pedestrians.

OSRM uses Lua profiles to define routing behavior.

  • Flexibility: By default, OSRM provides profiles for cars, bicycles, and pedestrians.
  • Custom Routing: If you operate a shipping company, you can customize the profile: “Ignore roads closed to trucks over 7.5 tons and prefer highways, even if it’s a detour.” This deep logical control is often not available with SaaS providers.

4. Operating Models Compared: Google Maps API vs. ayedo Managed OSRM

Here it is decided whether your growth is penalized by API costs or whether your infrastructure scales with you.

Scenario A: Google Maps Directions / Mapbox Routing (The API Tax)

SaaS routing is fantastic for occasional requests but fatal for core logistics.

  • Cost Explosion: Google’s “Distance Matrix API” is notorious. Those who operate fleet optimization by the minute quickly send tens of thousands of requests per day. Bills quickly run into thousands of euros.
  • Rate Limits: Cloud providers throttle you during API spikes. When your optimization algorithm plans the next day at night, it often runs into timeouts.
  • Data Privacy: You continuously send live coordinates of your fleet or end customers to third parties.

Scenario B: OSRM with Managed Kubernetes by ayedo

In the ayedo App Catalog, OSRM is provided as a high-performance in-cluster service.

  • Flatrate Routing: You pay for the worker nodes (RAM + CPU). Whether the algorithm calculates 10 or 10,000 routes per second costs exactly the same. This changes the entire software architecture, as developers suddenly no longer have to be “stingy” with routing requests.
  • Air-Gapped & Private: Zero data flows to the internet. Perfect for tracking cash transporters, government vehicles, or in high-security environments.
  • Scalability: Due to the stateless design of the OSRM engine, the service can be cloned (ReplicaSet) in Kubernetes as often as needed to handle massive load spikes.

Technical Comparison of Operating Models

Aspect Google Directions API ayedo (Managed OSRM)
Costs Pay-per-Request (Very expensive) Flatrate (Infrastructure)
Performance Good (but internet latency) Extremely fast (Local RAM)
Distance Matrix Costs per element/cell Free (Limited only by CPU)
Routing Profile Predefined Customizable (via Lua scripts)
Data Privacy Location data to Google 100% Sovereign (In-Cluster)
Strategic Risk High lock-in & costs Full Sovereignty

FAQ: OSRM & Location Strategy

How much RAM does OSRM need?

This is the crucial hardware factor. Since OSRM holds the graph in RAM, the memory requirement depends on the map section. Routing for all of Germany requires about 10–15 GB of RAM. For Europe, it’s quickly 50 GB. For the entire planet, you need servers with well over 128 GB of RAM. In the ayedo stack, we select the appropriate OSM extract exactly for your region to optimize costs.

Does OSRM consider current traffic (Live Traffic)?

This is the honest trade-off. OSRM calculates the historically fastest route based on static road data (speed limits). Out-of-the-box, it doesn’t have “real-time traffic data” like Google Maps. However, it is possible to inject traffic data (e.g., CSV files with reduced speeds) into the graph regularly via the MLD architecture. For 90% of B2B delivery planning, static routing (which can be supplemented with buffer times) is completely sufficient.

Can I combine OSRM with Nominatim?

Yes, this is the “dream team” of open-source geodata. You use Nominatim (geocoding) to translate the customer’s address into latitude/longitude. These coordinates are then fed into OSRM to calculate travel time and route. Both run sovereignly in your ayedo cluster.

Are there alternatives to OSRM?

Yes, in the open-source area, there are also Valhalla and GraphHopper. OSRM is traditionally the king in terms of pure speed (especially for distance matrices), while Valhalla is sometimes more dynamic in route planning over very large, dynamic distances. However, for highly scalable C2C and B2B logistics APIs, OSRM is the industry standard.

Conclusion

Geodata and routing are the backbone for many modern business models. Those who make themselves completely dependent on the API prices of large cloud corporations limit their own potential for optimization. OSRM delivers enterprise-grade routing speed based on OpenStreetMap. It gives developers the freedom to calculate millions of waypoint combinations without having to think about the budget with every HTTP call. With the ayedo Managed Stack, you get this high-performance logistics engine stable and maintenance-free directly into your own data center.

Ähnliche Artikel