Google Maps — System Design Interview

Phase 1: Clarify, Scope & Constraints

---

Interviewer: "Let's design Google Maps. How do you approach this?"

Candidate: "Google Maps is a large product. Let me identify the core subsystems and pick the most design-rich ones:

1. Map tile serving — Display the map: streets, terrain, satellite imagery, as a user pans and zooms
2. Routing/navigation — Find the fastest route from A to B, with real-time traffic
3. Search — Find places, addresses, POIs ('Starbucks near me')
4. ETA computation — Estimate arrival time accounting for live traffic

I'll focus on map tile serving and routing/navigation, as they're the most architecturally distinct and interesting. Search shares architecture with the Proximity Service design. ETA is a deep dive within routing.

The dominant complexity is routing at scale. The road graph of the continental US has ~20+ million nodes (intersections) and ~50+ million edges (road segments). Running Dijkstra on this naively takes seconds — too slow for real-time navigation. The question is: how do you compute optimal routes in milliseconds on a graph this large?

WHY: The secondary complexity is map tile serving. There are $4^{zoom\_level}$ tiles at each zoom level, with tiles at zoom 22 representing individual buildings. Serving tiles to 2 billion MAU efficiently — with 100ms load times across the globe — requires a sophisticated tile pyramid, CDN strategy, and intelligent caching.

Non-goals for V1:

• Street View (computer vision processing of 360° imagery)
• Indoor maps (separate data model)
• Public transit routing (different graph structure, schedule-dependent)
• Real-time satellite imagery updates
• User-submitted photos and reviews…