SDE Path

Geospatial routing & ETA

Design Google Maps

Hard

Route across a continent in milliseconds and predict arrival to the minute — while the traffic underneath never stops changing.

Google Maps is a geospatial platform: it draws the world as pannable map tiles, finds places by name or address, and computes the fastest route from A to B with a live ETA. What makes it a hard system-design problem is doing all three at planetary scale — and doing the routing over a road network with hundreds of millions of edges whose weights (travel times) change every minute as traffic moves.

Three problems are braided together:

  • Routing — shortest path over a continental road graph, fast enough to feel instant. Plain Dijkstra is far too slow, so the graph is precomputed into an index.
  • ETA with live traffic — turn a firehose of anonymous GPS probes into per-road-segment speeds, then price a route in seconds-of-travel that reflects current conditions.
  • Tiles & geocoding — serve a cacheable pyramid of map tiles and answer spatial queries (address ↔ point, what is near me) from a geospatial index.

The whole design is about picking the right precomputation for a graph whose weights won't sit still, and keeping the read-heavy tile path far away from the compute-heavy routing path.

Start by scoping the three coupled sub-problems — routing, live-traffic ETA, and tiles + geocoding — and separating the read-heavy map/tile path from the compute-heavy routing path. That split, plus the fact that edge weights change with traffic, drives every later decision. Keep the core list short: directions + ETA, tiles, and search are what you'd actually build in 45 minutes; turn-by-turn navigation and alternate routes are refinements of directions.

Functional

  • Directions — given an origin, destination, and travel mode, return the best route(s) (plus a few alternates) with distance and a traffic-aware ETA.
  • Live ETA & re-routing — estimate arrival from current traffic, update it continuously en route, and re-route when a materially faster path opens up.Re-routing is triggered by a wrong turn or by traffic changing the optimal path mid-trip.
  • Map rendering — pannable, zoomable maps served as tiles across many zoom levels, with a live-traffic congestion overlay.
  • Search & geocoding — forward geocode (address → point), reverse geocode (point → address), and nearby-POI search.

Non-functional

  • Low latency — a directions query returns < 1 s p99; a map tile loads < 100 ms from the CDN.
  • Fresh traffic — live segment speeds reflect probe data within ~1–2 min; ETA accuracy within ~10–15% of actual.
  • Read scale — sustain ~250k tile fetches/s and ~25k route requests/s at peak.
  • High availability99.9%+ for tiles and routing; degrade gracefully to historical traffic if the live pipeline stalls.
  • Global coverage — one routable graph of ~10⁸ intersections; cross-country routes supported.

Out of scope

  • Offline / downloaded maps
  • Street View & 360° imagery
  • Indoor maps and AR walking navigation
  • Business-listing management & reviews

Check yourself· 3 questions

Question 1

Beyond simple storage, what makes Google Maps a genuinely hard system-design problem?

Question 2

Why is 're-route as traffic changes' a defining requirement rather than a nice-to-have?

Question 3

Which item is correctly OUT of scope for a first-pass design?