Gaming & realtime, an interactive architecture walkthrough
Maps and navigation: how the architecture works
How a maps system serves vector tiles from a CDN, routes over a preprocessed road graph with live traffic weights, and builds traffic from GPS traces.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate.
Interactive diagram
Overview
A maps and navigation system draws a map, finds places, plans routes and guides drivers turn by turn using live traffic. Map data from several sources is merged and validated into one database, from which two products are built: vector tiles for display, cached by a CDN, and a preprocessed road graph for routing held in memory.
Routing searches the preprocessed graph, which uses shortcuts or a multi-level partition so a continent-wide query takes milliseconds, and applies current traffic speeds as edge weights at query time. Live speeds come from anonymised GPS traces that are map-matched to road segments in a streaming job. A separate geocoding index turns addresses and place names into coordinates. This is a simplified learning design, not any company's production system.
Trade-offs and what changes at scale
Heavier preprocessing makes queries faster but makes it slower to apply map changes and harder to support per-request options such as avoiding tolls, which is why some engines prefer partitions that allow costs to change at query time. Live traffic improves ETAs but depends on enough probe data on each road, so quiet roads fall back to historical speeds. Vector tiles move rendering work to the device and let one tile set serve any style. At larger scale the graph is split by region, and long routes are stitched across regional graphs.
How it works, step by step
The walkthrough above, as text. Each step lights up the components named under it.
The Map Builder imports open map data, imagery-derived features and partner feeds, checks them and writes roads, places and attributes such as turn restrictions to the Map DB. Bad map data becomes wrong directions, so changes are validated before release.
The Tile Builder cuts the map into vector tiles for each zoom level and writes them to the Tile Store. Each tile holds layers of features with geometry in coordinates local to the tile, so the client can style and rotate the map itself.
The Navigation App requests only the tiles in view, addressed by zoom, x and y, from the Tile CDN. Tiles are the same for every user, so almost all of them come from cache.
Typing a destination calls the Geocoding Service, which searches the Place Index for addresses and points of interest, ranked by text match and distance from the user. The chosen place becomes a coordinate for routing.
Ahead of time, the road network from the Map DB is preprocessed into a Routing Graph held in memory. Preprocessing is what turns a continent-wide shortest-path search into milliseconds per request.
The Routing Service searches the graph from the user's snapped position to the destination and returns the fastest route plus alternatives. Costs per edge depend on the travel mode, so car, bike and walking routes use different weights over the same roads.
Edge weights are adjusted at query time with current speeds from the Live Traffic Store. Applying traffic as weights avoids rebuilding the graph every few minutes.
The ETA Model corrects the route's travel time using historical patterns for that time of day and expected delays at turns and lights. Users judge the app by its arrival time, so this correction matters as much as the route itself.
Phones and vehicles that opted in send anonymised GPS traces to Probe Ingest, which publishes them to the Probe Stream. Traces carry no account id, only a short-lived trip id.
The Map Matcher snaps noisy GPS points to the most likely road segments and computes the current speed on each, writing it to the Live Traffic Store. Matching is needed because raw GPS points often fall between parallel roads.
During navigation, if the driver leaves the route or traffic makes another route faster, Rerouting asks the Routing Service for a new path from the current position. The app downloads the route once and follows it locally, so it only calls back on changes.
Place updates from the Map DB are re-indexed into the Place Index regularly, so new businesses and addresses become searchable. Search data can update on its own schedule, separate from the routing graph.
Sequence diagram
The same walkthrough as a UML sequence diagram, one lane per layer or group (19 components in all), left to right in the order a request reaches them, numbered by step. A loop on a lane is a step that stays inside that group. Solid arrows are synchronous calls, dashed are asynchronous.
Key components
Map Data Pipelinedomain
- Map Builder: merges, validates, builds road graph
- Map DB: roads, places, attributes (postgresql)
- Map Sources: open map data, imagery, partner feeds
- Tile Builder: cuts vector tiles per zoom level
Map Displaydomain
- Tile CDN: caches tiles near users
- Tile Store: vector tiles by z/x/y (s3)
Clientslayer
- Navigation App: map view, search, turn-by-turn
- Probe Vehicles & Phones: anonymised GPS speed traces
Searchdomain
- Geocoding Service: address or place to coordinates
- Place Index: addresses, POIs, geo points (elasticsearch)
Routingdomain
- ETA Model: adjusts times for time of day
- Rerouting: new route when the driver deviates
- Routing Graph: preprocessed road graph in memory
- Routing Service: fastest route, alternatives
Live Trafficdomain
- Live Traffic Store: current speed per segment (redis)
- Map Matcher: snaps traces to road segments (flink)
- Probe Ingest: receives speed traces
- Probe Stream: GPS points by road segment (kafka)
API Gateway
- API Gateway: auth, quotas, routing
Sources
Public writing this explainer draws on. Read these for what the real systems actually do.
Make it yours
Copy this diagram and its walkthrough into your own workspace, then change anything: swap Postgres for DynamoDB, add a cache, rewrite the narration. Free, and it uses no AI credits.
Related walkthroughs
- Real-time leaderboardHow a real-time leaderboard ranks millions of players with in-memory sorted sets, takes scores only from game servers, and rolls boards over by season.
- Multiplayer game backendHow a multiplayer game backend matches players by skill and latency, runs each match on an authoritative server, and processes results afterwards.
- Ride-hailing platformHow a ride-hailing platform streams driver locations, matches a rider to a nearby driver, prices the trip with surge, and takes payment.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate. Real systems differ in the details. Browse the library.