Low Level Design: Mapping Service

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. 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

• On tile generation failure, serve stale tile from cache with a short TTL; retry generation asynchronously.
• On database partition unavailability, route read queries to a replica; writes queue in a durable log (Kafka) and replay when the primary recovers.
• On a CDN origin miss storm, use request coalescing (one origin fetch serves many waiting clients) to prevent thundering herd on popular tiles.
• On 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.

See also: Netflix Interview Guide 2026: Streaming Architecture, Recommendation Systems, and Engineering Excellence

See also: Uber Interview Guide 2026: Dispatch Systems, Geospatial Algorithms, and Marketplace Engineering

See also: Scale AI Interview Guide 2026: Data Infrastructure, RLHF Pipelines, and ML Engineering