Trip Management · infrastructure brief

What the routing engine costs to run

The concern is that adding a routing engine to Trip Management brings a large, growing compute bill. It does not. Routing sits off the telemetry hot path entirely, so its cost is a fixed monthly box that does not move when the fleet grows. Every number below is measured on our own data.

The short version

  • Zero routing calls per GPS packet. The engine is touched once, when a planner publishes a route. Telemetry never reaches it.
  • Cost tracks map coverage, not fleet size. All of India now measured running in 232 MB of RAM, roughly $15 a month, flat whether we run 10 vehicles or 10,000.
  • Capacity is a non-issue. Measured at 2,270 routes/sec on 2 CPUs. Real demand is tens of requests a day.

Where routing is actually called

This is the whole concern, resolved. The expensive-sounding part and the high-volume part are two different paths that never meet.

high volume Live telemetry
vehicle GPS→ Kafka→ trip evaluation→ alerts & ETA

Millions of packets a day at fleet scale. Routing engine calls: none. Live ETA is computed from the stored route duration and a rolling average of the vehicle's own observed speed. No external lookup, no per-packet cost.

rare, human-triggered Route planning
planner clicks Publish→ routing engine→ road geometry saved once

One call per route, when a human defines or edits it. The result is written to the database and reused forever after. A route planned once is never re-planned by traffic.

Measured, not estimated

Benchmarked locally against real vehicle traces on a 2 CPU container.

2,270/s
Routes served per second, peak
4 ms
Median response time
232 MB
Memory held, whole of India plus a full city
1.7 s
Cold start
43 s
Full map rebuild, city
0
Per-vehicle or per-packet charges

Memory was identical idle and after 2,000 queries. The engine loads a map and answers from it; serving requests adds essentially nothing. The 232 MB figure is measured with the full India road network and all of Bengaluru loaded at once.

Sizing for all of India

These are no longer estimates. Built and measured on 27 August against the live 1.6 GB India map.

What is loadedOn diskActually in memory
All of India, main road network598 MB136 MB
Bengaluru, every street304 MB18 MB
Whole service, both together902 MB232 MB

The right-hand column is the one that gets billed, and it is roughly a quarter of the left. The engine reads its map straight off disk and keeps in memory only the parts we actually drive through, so covering the whole country costs little more than covering one city. This runs comfortably on the smallest instance any cloud sells.

Verified on real journeys across the country, not just inside one city:

JourneyDistanceEstimated time
Bengaluru to Mumbai975 km16.6 h
Delhi to Kolkata1,486 km21.6 h
Chennai to Hyderabad681 km12.7 h
Kevadia to Ahmedabad217 km3.9 h

Distances match real road distances to within a few percent. This matters because the cheap way to cover a country is to chop it into regional pieces, and every one of these journeys crosses a regional boundary. Our design keeps a country-wide layer permanently loaded precisely so these cannot silently fail.

Cost against scale

Move the sliders. The point is the shape of the two lines, not the exact rupee figure.

Self-hosted engine
$15
per month, all of India
Per-request map API
$2
per month, at list price

Self-hosted is one small server plus a disk, and a monthly map rebuild on a throwaway instance. The server figure now comes from the measured 232 MB footprint rather than an estimate. The API line is list price for basic directions requests. Both in USD, sized to be defensible rather than flattering.

What we are not claiming

The engine gives us good roads, not good timings

Tested against seven days of real vehicle traces, its road geometry matched where the driver actually went to within 7 metres on highway legs. Its travel time predictions were wrong by 53% on average, always optimistic, because Indian road data carries speed limits on only 2% of roads.

This is a limitation of public map data, not of the engine, and no paid setting fixes it. So we use the engine for the road path and take arrival times from our own historical vehicle speeds, which we already store. The same corridor measured between 15.8 and 31.5 km/h across days, and that variation is something only our own data knows.

The recommendation

  1. One country-wide layer, always loaded
    A permanent all-India layer covering the main road network, measured at 136 MB in memory. City-level detail loads on top of it only for the cities we actually operate in, and unloads when they go quiet. No route ever fails at a state border, because the country-wide layer can always answer.
  2. Road paths from the engine, arrival times from our own data
    Plays to the strength that measured well and avoids the weakness that measured badly. Costs nothing extra to build; we already collect the speed history.
  3. Rebuild the map monthly on a throwaway instance
    Roads do not move. The rebuild is a batch job that runs on cheap preemptible compute and hands a finished file to the small server, so peak build memory never sits in the monthly bill.
  4. Cache on the route definition
    Re-publishing an unchanged route should not call the engine at all. This alone removes most repeat traffic.

Why not simply buy a maps API

At our volume a commercial API is genuinely competitive on price, and that is worth saying plainly. The blocker is not cost. Commercial map terms restrict storing route results and expect the result to be shown on that provider's own map tiles. Trip Management stores every route permanently, because the saved road path is the corridor that deviation alerts are judged against and the evidence in a customer dispute, and it renders OpenStreetMap tiles. Self-hosting is the choice that keeps the data ours. The $15 is the smaller half of the argument.