What a Map Service Does

In one line: this is the first design in the course where the hard part is an algorithm, not storage or bandwidth. Everything else has been about moving bytes; this is about computing a path.

Where it gets used

Over five million businesses use the Google Maps API to integrate mapping systems into their applications.

Third-party integration changes the traffic profile completely

It is tempting to read the Waymo and Uber examples as product colour. They are a load characteristic, and Lesson 2 lists them explicitly in the scalability requirement — "high request volumes from individual users and enterprise integrations (e.g. Uber and Lyft)."

A human opens Maps a few times a day. Uber queries continuously — every driver's position, every rider's ETA, every route recalculation, for every trip in progress worldwide. An autonomous vehicle queries constantly by definition.

So a large share of traffic comes from machines, not people, and machine traffic has different properties: it is steady rather than bursty, latency-sensitive in a harder way (a car cannot wait), and it does not go to sleep at night.

That is why five million businesses on the API is the most load-relevant sentence in the lesson. It also means the 32 million daily active users in Lesson 3 undercounts the real query volume substantially — a point worth raising when the estimate looks small.

Notice what this system is not — it is not a bandwidth problem

The last three chapters were about moving bytes: YouTube at 12 Tbps, Quora at 226 Gbps, both read-dominated with delivery as the hard part.

Maps is different. Lesson 3 lands at 297 Gbps — comparable to Quora — and the data is largely static: over 20 PB of road data that barely changes day to day.

So neither storage growth nor bandwidth is the challenge. The challenge is stated plainly in Lesson 2: a graph with billions of vertices, and a shortest-path query that must return in two to three seconds.

That makes this the course's first genuinely algorithmic system design. The building blocks are familiar — load balancers, key-value stores, pub-sub — but the interesting work is partitioning a graph and precomputing paths, which none of the previous chapters needed.

The chapter's shape

A whole lesson group named 'meeting the challenges' is unusual and tells you where the difficulty is

Most design chapters go requirements → design → evaluation. This one inserts a dedicated stage for solving two named problems: scalability and ETA computation.

That structure is a signal. The architecture — load balancers, services, databases — is not the hard part and does not need much defending. The hard part is:

• Scalability: running shortest-path over a global graph fast enough.
• ETA accuracy: predicting travel time when it depends on traffic, weather, and construction rather than distance.

Both are genuinely difficult, and neither is solved by adding servers. That is worth recognizing in an interview — when the difficulty is algorithmic, drawing more boxes does not help, and the answer has to be about preprocessing, partitioning, and approximation.

The four building blocks the design asks you to identify

The chapter opens with an exercise: name four building blocks, given that the system needs to search locations, store key-value metadata, generate and handle events, and store road data as a graph.

The intended answers, confirmed by Lesson 3's list:

• Distributed search — searching locations on the map.
• Key-value store — segment metadata.
• Pub-sub — navigation events and location streams.
• Databases — specifically a graph database for the road network.

Plus load balancers, which every design uses.

Worth doing before reading ahead. The mapping from "structured graph format for storing and retrieving road data" to graph database is the one people miss, and it is the choice that most shapes this design.

Interview signal by level

Next: the requirements and the two hard problems.