1.6M/s
tile fetches at the evening peak
250M daily users × 3 sessions × 60 tiles is 45 billion a day. The CDN answers 98%, so the origin sees about 32k/s.
What goes inside a tile?
Bad: Server-drawn pixels
Each style, language and density is a separate set, ≈ 410 TB to zoom 18.
Good: Phone-drawn geometry
One vector set, ≈ 2 TB, serves night mode, Kannada labels and rotation.
Bengaluru to Mumbai, and Dijkstra searches Kerala
On Europe’s benchmark it scans 9.4M nodes in 2.5 s. Contraction Hierarchies add shortcuts offline; queries only climb to more important roads: a few hundred nodes, ≈ 0.2 ms.
Contraction Hierarchies bake weights into 10 minutes of preprocessing. Traffic changes every 60 seconds.
The trick
Customizable Route Planning: partition once, then recompute small cell overlays in about a second. Queries take ≈ 2 ms.
Hebbal flyover: on top, or on the road below?
840k points a second at peak, noisy by metres. Nearest-road snapping jumps a wall. An HMM knows there’s no ramp, so the trace stays up.
Leave at 4 p.m., reach the airport stretch at 5:15
Today’s speeds miss the jam that hasn’t formed yet. Price each segment at the time you’ll reach it, live first, then history; a model re-scores.
Navigation that survives tunnels
- The phone guides itself from the route
- Off route? It asks for a reroute
- Jams re-check only the drives they touch
- Switch only if it saves, say, 5 min and 10%
Remember
Tiles are static content on a CDN, routes are in-memory CRP per continent, traffic is a stream of anonymised probes. The phone guides itself; the server pushes changes.