What is a mapping service in system design?

A mapping service is a system that stores geospatial data and provides APIs for rendering maps, geocoding addresses, and routing between locations. It typically involves tile servers, spatial databases, and CDN distribution for scalable map delivery.

How do you design the low-level components of a mapping service?

Key low-level components include a tile storage layer (e.g., pre-rendered PNG or vector tiles stored in object storage), a tile server that serves tiles by zoom level and coordinates, a spatial indexing layer using quadtrees or geohashes, and a geocoding engine backed by a spatial database like PostGIS.

How does Google Maps handle map tile generation at scale?

Google Maps pre-renders billions of map tiles at multiple zoom levels and caches them on CDN edge nodes globally. Vector tiles are increasingly used to allow client-side rendering, reducing server load and enabling dynamic styling. Tile generation pipelines process raw geodata (roads, buildings, terrain) through rendering engines like Mapnik.

What data structures are commonly used in mapping services for spatial queries?

Mapping services rely on R-trees and quadtrees for efficient bounding-box and nearest-neighbor queries, geohashes for partitioning and sharding spatial data, and segment-based graph representations (adjacency lists) for road networks used in routing algorithms like Dijkstra's or A*.

Low Level Design: Mapping Service

⏱ 4 min read

What Is a Mapping Service?

A mapping service provides geographic data, visual map rendering, and spatial queries to clients. Think Google Maps or OpenStreetMap: users pan and zoom across a rendered map, search for places, and query distances or boundaries. At its core the service must store a massive graph of the physical world, render tiles efficiently, and answer geospatial queries at low latency.

Data Model

The world is represented as a weighted directed graph:

Node — a geographic point: (node_id BIGINT, lat DOUBLE, lon DOUBLE, elevation FLOAT)
Edge — a road segment between two nodes: (edge_id BIGINT, src_node BIGINT, dst_node BIGINT, length_m FLOAT, speed_limit SMALLINT, road_class ENUM('motorway','trunk','primary','secondary','local'), one_way BOOLEAN)
Place — a named entity (business, landmark): (place_id BIGINT, name TEXT, category VARCHAR(64), lat DOUBLE, lon DOUBLE, polygon GEOMETRY)
Tile metadata — pre-rendered raster or vector tiles indexed by (zoom, x, y) following the Slippy Map convention.

Spatial indexes (PostGIS, S2 geometry library, or H3 hexagonal grid) accelerate bounding-box and radius queries. The graph itself is partitioned by region using a technique like METIS or KD-tree decomposition so that cross-partition edges are minimized.

Core Components and Workflow

Tile Server

Map data is pre-rendered into tiles at each zoom level (0–20). A tile pipeline ingests OSM data, applies styling rules (Mapnik, Mapbox GL), and stores tiles in an object store (S3-compatible). A CDN sits in front, caching tiles by (zoom, x, y). Cache hit rates above 95% are typical for popular regions. On a cache miss, the tile server regenerates the tile on demand and warms the cache.

Geocoding

Forward geocoding (address → coordinates) uses an inverted index over place names combined with a spatial filter. Elasticsearch with geo_point fields or a custom trie structure handles fuzzy matching. Reverse geocoding (coordinates → address) uses a spatial join against administrative boundary polygons stored in PostGIS.

Spatial Query Engine

Bounding-box searches use R-tree indexes. Nearby searches use a Haversine filter combined with an index scan on a geohash prefix column, reducing candidate rows before exact distance computation.

Failure Handling

Tile generation failure: serve stale tile from cache with a short TTL; retry generation asynchronously.
Database partition unavailability: route read queries to a replica; writes queue in a durable log (Kafka) and replay when the primary recovers.
CDN origin miss storm: use request coalescing (one origin fetch serves many waiting clients) to prevent thundering herd on popular tiles.
Geocoding index corruption: maintain a blue/green index pair; promote the green index after a successful rebuild before cutting over traffic.

Scalability Considerations

Tile serving is stateless and horizontally scalable; add CDN edge nodes near user population centers.
The graph database shards by geographic region; inter-shard queries (cross-border routes) are handled by a thin routing layer that stitches partial paths.
Read replicas handle the heavy geocoding read load; writes (map edits) go through a change queue processed by a dedicated ingestion service.
Hot-spot tiles (e.g., city centers at zoom 14) benefit from in-memory caching (Redis) in front of the object store.

Summary

A mapping service is built around three pillars: a graph database of nodes and edges for the road network, a tile pipeline for visual rendering, and a spatial query engine for geocoding and proximity search. Reliability comes from aggressive caching, replicated storage, and graceful degradation to stale data. Scalability is achieved by treating tile serving as a static asset problem and sharding the graph by geography.