SysPad › Examples › Google Maps
Google Maps
Navigation loads precomputed routing tiles from object storage and prices every route against a Live Traffic store; that store is fed by a firehose of user location pings streaming through Kafka; map images serve straight from a CDN; and the tiles themselves are rebuilt offline, never edited live.
One shared traffic store as the meeting point of two opposite workloads - a high-volume ping stream writing it and every routing query reading it - plus precomputation as an architecture: the online paths only read tiles that an offline batch produces.
- Throughput: 20,000 req/sec
- First to saturate: Nothing at this load
- Estimated cost: $115k/mo
How it works
- Load Balancer
- Path routing: /directions to the Navigation Service, /location to the ingest tier. Map tiles skip it entirely and hit the CDN directly, so image traffic never competes with the dynamic API. Multi-AZ so a zone loss never takes routing down (availability NFR).
- Navigation Service
- Geocodes the destination in-memory, loads the routing tiles the route crosses, and prices the ETA against Live Traffic. Stateless, so it autoscales for rush-hour spikes; the heavy road-graph data lives in the tiles it loads, not in the service.
- Routing-Tile Cache
- Hot routing tiles - dense metros, popular corridors - kept in memory so the common query never touches object storage. A miss reads the tile from S3 and warms the cache. Sharded because the global tile set is far larger than one node.
- Routing Tiles
- The road network precomputed into tiles at several zoom levels and stored as objects, not queried as a live graph. The router loads only the tiles a route crosses, which is what makes continental routing tractable. Rebuilt offline when map data changes, never edited in place.
- Live Traffic
- Current speed per road segment, written by the Traffic Processor and read by every routing query for its ETA. This is the shared state where the location-ping firehose and the navigation path meet - the single busiest node in the design.
- Location Ingest
- Absorbs the location-ping firehose - every active navigator reports every few seconds - and does nothing but validate and forward to the stream. Thin and massively concurrent so a traffic spike never blocks the caller.
- Location Stream
- Kafka-style durable log of location pings. Decouples ingest rate from processing rate and lets independent consumers read the same pings - the Kafka design.
- Traffic Processor
- Windows the ping stream per road segment to estimate live speeds (writing Live Traffic) and records each user’s latest position (writing the location store). Two sinks, one pass over the stream.
- User Location DB
- Latest known position per user with a short TTL, for resume-navigation and nearby features. Losing a point is harmless - the next ping replaces it - so it is a fast KV store, not a system of record.
- Map-Tile CDN
- Pre-rendered map images served from the edge; ~97% never reach origin. Rendering is a read-only, cache-everything problem kept completely off the dynamic API path.
- Routing-Tile Builder
- Offline Spot batch that turns fresh map data into both the routing tiles and the rendered map images. Precomputation is why the online paths only ever READ - the expensive graph and image work happens here, on a schedule, never on the request path.
Request flows
Get directions
- Client
- Load Balancer
- Navigation Service
- Routing-Tile Cache
- Routing Tiles
- Live Traffic
Report my location
- Client
- Load Balancer
- Location Ingest
- Location Stream
- Traffic Processor
- Live Traffic
- User Location DB
Load map tiles
- Client
- Map-Tile CDN
- Map Tiles
Offline tile rebuild
- Tile-Build Schedule
- Routing-Tile Builder
- Routing Tiles
- Map Tiles