Resource Estimation

In one line: the estimation here produces a genuinely surprising split — the response is 2 MB of pictures and 5 KB of directions, so 99.75% of the bandwidth carries something the routing algorithm never touches.

Servers

Servers = 32,000,000 / 64,000 = 500 servers

500 servers is strikingly small — and worth interrogating rather than accepting

Compare the other chapters: YouTube needed 8K servers, Quora 4.7K. Maps needs 500, using the same DAU-as-peak-RPS heuristic.

The difference is simply the DAU assumption — 32 million here against 300–500 million there. That is low for a service Lesson 1 says has five million businesses on its API and powers Uber and Waymo.

Two things worth saying about it:

The user count almost certainly undercounts machine traffic. An Uber driver's app queries continuously; a person opens Maps a few times a day. Enterprise integration traffic does not appear in a "daily active users" figure at all.

But the routing servers are not what 500 is really counting. Lesson 12 makes the architecture clear: segments are hosted on separate servers, and the count of those is driven by how many segments exist and how large each is, not by request rate. A world partitioned into 5×5-mile segments is a very large number of segments.

So this figure sizes the request-handling tier, and the segment-hosting tier is sized by geography instead. Saying that distinction out loud is stronger than either accepting or dismissing the number.

Storage

Map data is largely static. While the system stores over 20 PB of road data, daily updates are negligible compared to that total. Therefore, storage requirements remain relatively stable.

Static data is a gift — and it is what makes precomputation viable at all

This is the most consequential property in the chapter, and it is easy to skim past because "storage is stable" sounds like the absence of a problem.

Compare the previous chapters. YouTube added 900 GB/minute; Quora added 116 TB/day. Both grow relentlessly, so their capacity plans are about absorbing growth.

Maps has 20 PB that barely changes. Roads are built occasionally; intersections do not move.

That unlocks the entire scalability strategy. Lessons 5 and 7 precompute shortest paths and cache them, which is only sensible because the underlying graph is stable — precomputing over data that changes hourly would mean constant invalidation and the cache would never pay for itself.

The general principle: precomputation is worth it in proportion to how stable the input is. Static structure plus dynamic weights, which is exactly what a road network is, is the ideal case — you precompute the structure once and update only the weights.

Note the qualifier that follows in Lesson 9, though: the graph is static, but edge weights are not. So the precomputed paths do need refreshing as traffic changes, which is what the graph preprocessing service in Lesson 11 exists for.

Bandwidth

Requests/second = 32,000,000 users x 50 requests / 86,400 s
                = 18,518 requests per second

Incoming — source and destination at 200 bytes:

18,518 x 200 B x 8 = ~29.63 Mb/s

Outgoing — responses of about 2 MB (2 MB visual + 5 KB text):

18,518 x 2,005 KB x 8 = ~297.03 Gb/s

Egress is 10,000x ingress — the most extreme asymmetry in the course

297,030 Mb/s / 29.63 Mb/s = ~10,000x

YouTube was 25x. Quora was 20x. Maps is four orders of magnitude, and the reason is that the request is tiny while the response is a picture.

But the more useful observation is what is inside the response:

Map visuals : 2,000 KB   =  99.75%
Text directions:  5 KB   =   0.25%

The actual answer to the routing question is 5 KB. Everything else is imagery.

Three consequences follow, and they reshape where you would spend effort:

Map tiles are a CDN problem, not a routing problem. Tiles are static, identical for every user viewing the same area, and enormously cacheable — the classic edge-caching workload. They should never touch the routing servers.

Optimizing the routing path saves almost no bandwidth. Making the shortest-path algorithm twice as efficient improves latency, not egress.

The real bandwidth lever is tile delivery — better compression, vector tiles instead of raster, and aggressive client-side caching, since a user panning around re-requests adjacent tiles constantly.

So this system has two nearly independent subsystems: a compute-bound routing service handling 5 KB answers, and a bandwidth-bound tile service handling 2 MB payloads. The rest of this chapter is entirely about the first one, and it is worth noting that the second is where all the bytes are.

Two sizing notes that are easy to get wrong. Map tiles dominate the bytes and are almost entirely cacheable, so a CDN removes most of that load rather than the origin carrying it. And location updates are not requests — the client pushes position continuously, so that tier is sized in concurrent connections.

Building blocks

Distributed search is here for geocoding — turning a name into coordinates

Its role is specific and easy to under-read: users type "Golden Gate Bridge", and routing needs latitude and longitude.

That translation — geocoding — is a search problem, and it is exactly distributed search's building block: an index mapping place names to coordinates, queried by keyword, ranked by relevance since "Springfield" matches many places.

Lesson 4's area search service consumes it directly: "it resolves latitude/longitude for the design and destination using distributed search."

Worth noting the ordering dependency — geocoding happens before routing, and it is on the critical path. If it takes 500 ms of the 2–3 second budget, the routing algorithm has correspondingly less. That is another reason the graph work needs to be precomputed rather than done live.

Interview signal by level

Next: the architecture.