Design Google Maps (Routing, ETA & Map Tile Serving)

Most candidates treat Google Maps as a single system — it is not. It is three fundamentally different engineering problems bundled into one product, each with distinct scale characteristics, data models, and latency requirements. Conflating them in an interview signals you have not thought deeply about the system. Problem 1: Map tile serving. The visual map is composed of millions of static image tiles. At zoom level 14, the world is divided into ~268M tiles. Serving these tiles to 1B+ monthly active users at negligible latency is a CDN caching problem, not a database problem — >99% of tile requests must be cache hits at zoom levels below 12. Problem 2: Routing on a massive graph. The road network for the contiguous US (CONUS) alone has ~36M nodes and ~58M directed edges. Computing the shortest path from New York to Los Angeles on this graph naively takes minutes with Dijkstra. Google routes it in under 10ms — not by using a faster computer, but by running a fundamentally different algorithm: Contraction Hierarchies (CH), a preprocessing technique that computes shortcut edges offline so online queries skip irrelevant portions of the graph. This is the single most important thing most candidates don't know: routing is a preprocessing problem, not a real-time algorithm problem. Problem 3: ETA from live traffic. A route's travel time depends on current road speeds, which change every few seconds. ~100M Android/Waze devices anonymously report GPS locations; Google aggregates these into per-segment speed estimates and re-weights the routing graph in near real-time. The ETA prediction then layers ML on top — accounting for historical patterns, day-of-week, weather, and events — to achieve ~3% median error on highways and ~10% in dense cities. An interview that conflates these three problems or treats any one of them shallowly will not pass the senior bar.