case-study

Global Map Serving: Precomputed Tiles at Planet Scale

also called Map Tiles, Tile Pyramid

Rendering a map view on demand is impossible at global scale, so the world is precomputed into a pyramid of cacheable tiles addressed by coordinate and zoom.

google-mapscachingprecomputationgeospatial

The problem

A mapping service like Google Maps serves an enormous number of concurrent viewers, each looking at an arbitrary location at an arbitrary zoom level. Rendering each view on demand from raw geographic data — roads, buildings, labels, terrain — would require far more compute than any plausible fleet.

The data is also very large and changes at wildly different rates: coastlines essentially never, road geometry occasionally, business listings frequently, and traffic conditions continuously.

The approach

Precompute into a tile pyramid. The world is divided into square tiles at each zoom level, each tile addressed by a deterministic coordinate. A view is assembled client-side from a small number of tiles.

Three properties follow, and they are why this design has been the standard for two decades:

Tiles are immutable and deterministically addressed, so they are perfectly cacheable — in the browser, at the edge, and at intermediate caches. The overwhelming majority of requests never reach an origin.

Popularity is extremely skewed. A small fraction of tiles — dense city centres at common zoom levels — account for a very large share of requests, so a modest cache achieves a very high hit rate.

Update cost is bounded to the affected area. A changed road re-renders the tiles covering it, not the planet.

Vector tiles refine this further: send geometry rather than rendered images, so the client renders labels and styling — allowing rotation, restyling and higher-resolution displays from the same cached data.

The layering that makes it work

Static base geometry is cached aggressively for long periods. Frequently changing overlays — traffic, live business information — are served separately with short lifetimes and composited by the client. Mixing them into one artefact would force the cache lifetime of the whole thing down to that of its most volatile component.

The transferable lesson

Separate content by rate of change and cache each accordingly. The most common caching failure in web architecture is exactly this: personalising or dynamically composing a page makes the entire response uncacheable, when the volatile portion was a small fragment that could have been fetched separately.

And the general pattern: precompute the deterministic part, address it immutably, compose at the client. It applies to far more than maps.