System Design: Maps Platform (Navigation, Routing, and Map Rendering)
Goal: Build a mapping and navigation platform that serves 1 billion daily active users, renders map tiles for 20 billion tile requests per day, and computes routes for 5 billion routing requests per day.
It also processes 50 million real-time location updates per second from navigators, background app users, fleet vehicles, and connected cars.
Support turn-by-turn navigation, multi-modal routing (driving, walking, cycling, transit), real-time traffic overlays, offline maps, and POI search across 500 million points of interest in 200+ countries.
1. Problem Statement
A mapping and navigation platform answers three questions billions of times per day: "What does this area look like?" (map rendering), "How do I get from A to B?" (routing), and "What is nearby?" (search). Each question has a different computational profile and a different scaling challenge.
Four core problems make this hard:
Routing at scale. 5 billion route requests per day means ~58,000 routes per second. A road network is a weighted directed graph with hundreds of millions of nodes (intersections) and over a billion edges (road segments). Running Dijkstra's algorithm on the full graph takes seconds per query. At 58K queries/sec, that is computationally infeasible. The system must answer arbitrary point-to-point routes in under 200ms.
Map rendering. 20 billion tile requests per day across 23 zoom levels. Zoom 0 shows the entire world in a single tile. Zoom 18 shows individual buildings. The total tile space at zoom 18 alone is ~69 billion unique tiles. Generating tiles on demand at this request rate is impossible. The system must serve tiles with < 50ms latency at the CDN edge.
Real-time traffic. 50 million location updates per second from all sources: active navigators (~15M/sec at 3-5 second intervals), background location sharing from app users not actively navigating (~10M/sec at 30-60 second intervals), fleet and logistics vehicles (~5M/sec), and OEM connected car telemetry (~20M/sec). Each GPS ping must be matched to the correct road segment, aggregated into road-level speed data, and reflected in ETA calculations within 30 seconds. Stale traffic data produces inaccurate ETAs that erode user trust.
Map freshness. The road graph and tile data are not static. Roads are built, demolished, rerouted. Buildings appear and disappear. Speed limits change. The system must continuously ingest data from three sources (satellite imagery, vehicle GPS probes, and community edits), validate it, and propagate changes to tiles and the routing graph within hours for critical updates. A map that shows a road demolished 6 months ago erodes trust as fast as a wrong ETA. The full data lifecycle runs: satellite imagery + vehicle probes + community edits -> validation -> PostgreSQL -> tile rebuild + graph reprocessing -> routing/ETA/navigation.
Scale:
- 1 billion DAU
- 20 billion tile requests/day
- 5 billion route requests/day
- 50 million GPS location updates/sec
- 500 million POI records
- 200+ countries with road network data
The core question: How to preprocess a road graph of hundreds of millions of nodes so that arbitrary point-to-point routes can be answered in milliseconds, not seconds, while reflecting real-time traffic conditions.
Common mistakes:
- Run Dijkstra on the full global graph for every route request (too slow by 1,000x)
- Store every GPS ping in a relational database (50M writes/sec kills any RDBMS)
- Use Geohash as the primary spatial index (boundary discontinuities cause missed results)
2. Functional Requirements
| ID | Requirement | Priority |
|---|---|---|
| FR-01 | Map tile rendering and serving (vector tiles, 23 zoom levels) | P0 |
| FR-02 | Point-to-point routing (driving, walking, cycling) | P0 |
| FR-03 | Turn-by-turn navigation with real-time voice guidance | P0 |
| FR-04 | Real-time traffic overlay on map tiles | P0 |
| FR-05 | ETA calculation with traffic-aware predictions | P0 |
| FR-06 | POI search (text search + geospatial filtering + ranking) | P0 |
| FR-07 | Geocoding (address to coordinates) and reverse geocoding | P0 |
| FR-08 | Automatic re-routing on deviation from planned route | P0 |
| FR-09 | Multi-modal routing (driving + walking + transit combined) | P1 |
| FR-10 | Offline map download (tiles + routing graph for a region) | P1 |
| FR-11 | Traffic incident detection and reporting | P1 |
| FR-12 | Speed camera and hazard alerts | P1 |
| FR-13 | Historical traffic patterns for departure time planning | P1 |
| FR-14 | Street View imagery | P2 |
| FR-15 | Indoor maps for large venues (airports, malls) | P2 |
| FR-16 | Elevation-aware routing (cycling, walking) | P2 |
3. Non-Functional Requirements
| Requirement | Target |
|---|---|
| Route computation latency (p99) | < 200ms |
| Tile serving latency (p99) | < 50ms (CDN hit), < 200ms (origin) |
| ETA accuracy | Within 10% of actual travel time (p90) |
| POI search latency (p99) | < 100ms |
| Location update ingestion | 50M updates/sec sustained (all sources: navigators, background, fleet, OEM) |
| Map data freshness (traffic) | < 30 seconds from GPS update to map overlay |
| Availability | 99.99% |
| Offline map package generation | < 5 minutes for a metro area |
| Concurrent active navigators | 50M |
| Total POI records | 500M |
| Road network nodes (global) | ~500M intersections, ~1.2B road segments |
These targets represent Google Maps-scale. See Section 15 for how the architecture simplifies at smaller scale.
4. High-Level Approach & Technology Selection
🔒 Premium section
5. High-Level Architecture
🔒 Premium section
6. Back-of-the-Envelope Estimation
🔒 Premium section
7. Data Model
🔒 Premium section
8. API Design
🔒 Premium section
9. Deep Dives
🔒 Premium section
10. Identify Bottlenecks
🔒 Premium section
11. Failure Scenarios
🔒 Premium section
12. Deployment Strategy
🔒 Premium section
13. Observability
🔒 Premium section
14. Security
🔒 Premium section
15. Building This at Startup Scale
🔒 Premium section
Explore the Technologies
🔒 Premium section
