Design Google Maps

01The design, in the six-step framework

1. Requirements

Functional

• Show a map at any zoom level anywhere on Earth, panning smoothly.
• Route between two points for driving, with an estimated time of arrival that reflects current traffic.
• Search for a place by name and show it on the map.
• Turn-by-turn navigation that re-routes when the driver deviates.
• Out of scope: Street View, transit schedules, offline maps, place reviews.

Non-functional

• 1 billion monthly users; 50 million concurrent navigation sessions at peak.
• Map tiles start rendering in under 100 ms; a route in under 500 ms, p95.
• Traffic-aware ETAs within 10 percent of actual for most trips; traffic data no older than 2 minutes.
• Map data updates (new roads, closures) visible within hours.
• Navigation must keep working for a minute without the server.

2. Core entities

• Road segment: segment_id, geometry, length, speed limit, restrictions, connected segments.
• Tile: zoom, x, y, version, rendered image or vector data.
• Place: place_id, name, location, category, address.
• Traffic sample: segment_id, minute, average speed, sample count.
• Route: origin, destination, segment list, ETA, computed_at; a navigation session holds one.

3. API

• GET /tiles/{z}/{x}/{y}?v=…: vector tile; served by the CDN. Called by the map view.
• GET /route?from=…&to=…&mode=drive: segments, geometry, ETA, alternatives.
• GET /places/search?q=…&near=…: ranked places.
• POST /navigation/{session}/location: the phone's position every few seconds; returns a re-route if needed. Called by the navigation client.
• GET /traffic/{segment_ids}: current speeds for a viewport's segments (internal to tiles and routing).

4. High-level design

Asking for directions:

1. The app shows the map by fetching vector tiles for the viewport from the CDN; tiles are versioned, immutable and cached at the edge.
2. The user types a destination; places search queries the geospatial index biased toward the viewport and returns the top places.
3. The route request goes to the routing service for the region containing both endpoints; it snaps the endpoints to the nearest road segments and runs a hierarchical shortest path with edge weights that are the current speeds from the live-speed cache.
4. The response carries the segment list, geometry and ETA; the app renders it and begins navigation.
5. Every 5 s the app posts its location; the server matches it to the route, updates the ETA with fresh speeds, and returns a new route if the driver left the planned one.
6. The same location reports feed the traffic aggregator, which computes per-segment speeds per minute and writes them to the live-speed cache; the loop from phones to traffic to ETAs closes within about two minutes.

5. Deep dives

How does a cross-country route come back in 500 ms?

Plain Dijkstra on a billion-segment graph is seconds to minutes. The routing service uses precomputed hierarchies: a one-off preprocessing step ranks roads by importance and adds shortcut edges so a query climbs from local streets to highways on both ends and meets in the middle, touching a few thousand nodes. The graph is partitioned by region with overlapping borders so a query within a region is one machine; a route crossing regions is computed on the highway layer, which is small enough to hold everywhere. Preprocessing runs when the map data changes, in hours, and is published as a versioned snapshot the routers load without downtime.

How do live speeds change routes without recomputing the whole hierarchy?

Combine the last two: speed profiles for the expected pattern and live weights overlaid at query time, so an accident reroutes drivers within two minutes.

How are tiles both fresh and cacheable at a 99 percent hit rate?

Tiles are rendered ahead of time from the map database into vector tiles per zoom level and stored as immutable objects named by version. The app requests a tile version it learns at start-up, so the CDN never serves a mixed map. When the map data changes, only the tiles whose area changed are re-rendered and published under the new version; untouched tiles keep their object and their cache entry, which is the precompute choice that makes the 100 ms target possible. Rendering on demand would make every pan a server round trip.

How does the traffic pipeline turn 10 million reports a second into speeds, and what about privacy?

Reports are map-matched to a road segment (a nearest-segment lookup in the geospatial index with heading as a tiebreak) and aggregated by segment and minute in a streaming job with a two-minute window; a segment needs a minimum number of samples before its speed is published, and it falls back to the historical profile otherwise. Reports are keyed by a rotating session id rather than a user id, kept only for the aggregation window, and never joined to accounts, which keeps the pipeline useful without storing anyone's trips.

What does navigation do when the server is unreachable for a minute?

The route response includes the full segment geometry and the turn list, so the phone can keep matching its GPS position against the route and announcing turns with no server at all. Re-routing when the driver deviates needs the graph, which the phone does not have unless an offline region was downloaded, so the app keeps following the last route and retries the server with backoff; the one-minute requirement is met by the client holding the route rather than by server redundancy, which is a reminder that some availability lives on the client.

6. What a strong answer sounds like

• Split the product into three systems with different shapes: tiles (static, CDN), routing (graph in memory with precomputation), traffic (a stream), and say how they connect.
• Quote the graph size (about 100 GB), the tile count and CDN hit rate, and the 10 million reports a second.
• Explain why precomputed hierarchies make routing fast and how live speeds are layered on top.
• Expect follow-ups on map-matching noisy GPS, on alternatives and avoid-tolls constraints, and on offline navigation (the client holds a region's graph).
• A common mistake is to propose a database query for routing; the graph must be in memory with precomputed structure.

02Where this question was reported

• IGotAnOffer · TPM list: 'Design Google Maps'
• IGotAnOffer · 'mapping service like Google Maps' (Google TPM, Glassdoor-sourced)
• Exponent · 'a Google-scale product such as Maps or YouTube'
• DesignGurus · Called 'one of the most common' Google SD questions
• DesignGurus · Listed; map storage, routing, concurrency
• Educative · First of 10, detailed
• System Design Handbook · 'Google Maps or a Location-Based Service'
• System Design Handbook · Only question with a worked example on the page
• Prepfully · Sample question, Hard
• Codemia · Listed
• PracHub · PM variant: 'system path of a Google Maps search, keystroke to results'
• PracHub · PM variants: Maps live location sharing; 100 ms Maps load latency budget