System Design Question 14: Design Google Maps – Maps, Search, Routing, Traffic, Navigation & Places

Design a scalable mapping platform for search, navigation, routing, traffic, places, reviews, geocoding, and real-time location services.

Note to Readers

Google Maps is one of those systems where each major component could easily be an article of its own. To keep this post practical and interview-focused, I’ve intentionally stayed at a high level and focused on the key building blocks, trade-offs, and architecture decisions.

I’m also conducting a two-part deep-dive live sessions on Google Maps System Design. Each session will include a 90-minute deep dive and 30 minutes of Q&A, and will be offered in both IST (Event Link) and PST(Event Link) time zones.

We’ll go much deeper into architecture, data models, routing, traffic processing, scalability challenges, and interview-specific approaches to solving such problems.

If there are other System Design topics you’d like to be conducted feel free to share your suggestions.

For System Design coaching, mock interviews, or mentorship, you can connect with me on LinkedIn, IGOA, or MeetAPro.

1. Understand Question as User

We need to design a Google Maps-like system that supports:

• Map rendering

• Search for places

• Geocoding and reverse geocoding

• Route planning

• Turn-by-turn navigation

• Real-time traffic

• ETA calculation

• Places, ratings, reviews, photos

• Offline maps

• Location sharing

• Business listings

• Observability and abuse prevention

The system should work globally, support billions of users, and provide low-latency location-based services.

---

2. Requirement Gathering

2.1 Functional Requirements

Map Rendering

Users should be able to open the app and see map tiles for their current area.

Support zoom levels, satellite view, street view, terrain view, and labels.

Search / Places

Users can search:

• Restaurants

• ATMs

• Petrol pumps

• Hospitals

• Addresses

• Landmarks

• Businesses

Return ranked results based on proximity, relevance, popularity, ratings, and freshness.

Geocoding

Convert address → latitude/longitude.

Example:

"India Gate, Delhi" → 28.6129, 77.2295

Reverse Geocoding

Convert latitude/longitude → human-readable address.

Example:

28.6129, 77.2295 → India Gate, New Delhi

Routing

Find best route between source and destination.

Support: Car, Bike, Walking, Public transport, Cycling, Multiple stops

Navigation

Provide turn-by-turn navigation.

Show: Current location, Next turn, Distance to next turn, ETA, Lane guidance, Re-routing if user deviates

Real-Time Traffic

Collect speed/location signals from users.

Detect congestion, accidents, road closures, slowdowns.

Update ETA dynamically.

Places, Reviews, Ratings

Businesses can have:

• Name, Category, Address, Photos, Opening hours, Ratings, Reviews, Phone number, Website

Offline Maps

Users can download map regions and use basic navigation without internet.

Location Sharing

Users can share live location with friends/family for a limited time.

---

2.2 Non-Functional Requirements

Scalability

Support billions of users and millions of QPS globally.

Low Latency

Search and map tile loading should be fast.

Routing should return within a few hundred milliseconds to a few seconds.

Accuracy

Location, ETA, address, traffic, and routes should be highly accurate.

Availability

Maps should work even during partial service failures.

Freshness

Traffic and road closures must be updated near real time.

Privacy

User location is highly sensitive. Must enforce strong privacy controls.

Global Support

Support multiple countries, languages, address formats, currencies, road rules, and transport systems.

---

2.3 Out of Scope

We will not deeply design:

• Street View image collection

• Satellite image processing

• Full public transit agency integrations

• ML ranking model internals

• Ad platform integration

---

3. BOE / Capacity Estimation

Assume:

• 1 billion daily active users

• 100 billion map tile requests/day

• 5 billion place searches/day

• 1 billion route requests/day

• 500 million active navigation sessions/day

• 50 million live traffic contributors at peak

Map Tile Requests

100B/day = ~1.15M requests/sec average
Peak could be 5M–10M QPS

Search Requests

5B/day = ~58K QPS average
Peak could be 500K+ QPS

Routing Requests

1B/day = ~11.5K QPS average
Peak could be 100K+ QPS

Location Pings During Navigation

If 50M users send location every 5 seconds:

50M / 5 = 10M location pings/sec

This is the heaviest real-time pipeline.

Storage

Map graph, places, reviews, photos, traffic history, and location events can easily reach petabytes.

---

4. High-Level Design

4.1 Core Services

Google Maps can be split into these major services:

1. Map Tile Service

2. Place Search Service

3. Geocoding Service

4. Reverse Geocoding Service

5. Routing Service

6. Navigation Service

7. Traffic Service

8. Places / Business Profile Service

9. Reviews & Ratings Service

10. Location Sharing Service

11. Offline Maps Service

12. Notification Service

13. Data Ingestion Pipeline

14. Monitoring & Observability Service

---

5. Databases and Storage Choices

5.1 Map Tile Service

Use Case

Serve map images/vector tiles quickly.

Storage

• Object storage: S3/GCS-like storage

• CDN cache

• Tile metadata DB

Why

Map tiles are read-heavy and cacheable.

Use CDN aggressively.

---

5.2 Places Search Service

Use Case

Search nearby places and businesses.

Storage

• Elasticsearch / OpenSearch for text search

• Geospatial index for nearby queries

• Postgres/Cassandra for source of truth

Why

Need both text search and geo-search.

Example query:

restaurants near me

Need ranking by:

• distance

• rating

• popularity

• open now

• user intent

• freshness

---

5.3 Geocoding Service

Use Case

Address → coordinates.

Storage

• Address index

• Trie / inverted index

• Geo-spatial DB

• Search engine

Why

Addresses are messy and country-specific.

Need fuzzy matching.

---

5.4 Reverse Geocoding Service

Use Case

Coordinates → address.

Storage

• Spatial index

• Polygon database

• Administrative boundary DB

Why

Given a point, find:

• street

• locality

• city

• state

• country

• postal code

---

5.5 Routing Service

Use Case

Find best path between source and destination.

Storage

• Road graph database

• Precomputed routing graph

• Traffic overlay cache

Data Model

Road network is a graph:

Node = intersection / road point
Edge = road segment
Weight = travel time / distance / traffic-adjusted cost

Algorithms:

• Dijkstra

• A*

• Contraction Hierarchies

• Multi-level graph partitioning

---

5.6 Traffic Service

Use Case

Real-time traffic speed and congestion detection.

Storage

• Kafka/PubSub for location pings

• Stream processor: Flink/Spark Streaming

• Time-series DB

• Redis for current traffic state

• Data lake for historical traffic

Why

Traffic is real-time and high-volume.

---

5.7 Reviews & Ratings Service

Use Case

Store reviews, ratings, photos, moderation signals.

Storage

• Cassandra / DynamoDB for high-write review storage

• Elasticsearch for review search

• Object storage for photos

---

6. APIs

6.1 Map Tile API

GET /maps/tiles/{z}/{x}/{y}

Response:

{
  "tileUrl": "https://cdn.maps.com/tiles/12/234/567.vector"
}

---

6.2 Search API

GET /places/search?query=restaurants&lat=28.61&lng=77.20&radius=5000

Response:

{
  "results": [
    {
      "placeId": "p123",
      "name": "ABC Restaurant",
      "lat": 28.61,
      "lng": 77.21,
      "rating": 4.4,
      "openNow": true,
      "distanceMeters": 850
    }
  ]
}

---

6.3 Geocoding API

GET /geocode?address=India Gate Delhi

Response:

{
  "lat": 28.6129,
  "lng": 77.2295,
  "formattedAddress": "India Gate, New Delhi, India"
}

---

6.4 Reverse Geocoding API

GET /reverse-geocode?lat=28.6129&lng=77.2295

Response:

{
  "address": "India Gate, New Delhi, India"
}

---

6.5 Routing API

POST /routes

Payload:

{
  "source": {
    "lat": 28.61,
    "lng": 77.20
  },
  "destination": {
    "lat": 28.45,
    "lng": 77.02
  },
  "mode": "CAR"
}

Response:

{
  "routeId": "r123",
  "distanceMeters": 32000,
  "etaSeconds": 2700,
  "polyline": "...",
  "steps": [
    {
      "instruction": "Turn right onto Ring Road",
      "distanceMeters": 500
    }
  ]
}

---

6.6 Navigation Update API

POST /navigation/update

Payload:

{
  "sessionId": "nav123",
  "userId": "u123",
  "lat": 28.62,
  "lng": 77.21,
  "speed": 42,
  "heading": 90,
  "timestamp": 1710000000
}

---

6.7 Location Sharing API

POST /location/share

Payload:

{
  "userId": "u123",
  "sharedWith": ["u456"],
  "durationMinutes": 60
}

---

7. Deep Dive into Core Services

A. Map Tile Service

Responsibilities

• Serve map tiles based on zoom/x/y

• Support vector and raster tiles

• Use CDN for global low-latency delivery

• Update tiles when roads/businesses change

Flow

1. User opens map.

2. Client calculates visible tile coordinates.

3. Client requests tiles.

4. CDN serves cached tiles.

5. If cache miss, request goes to Tile Service.

6. Tile Service fetches tile from object storage

7. Response is cached at CDN.

Corner Cases

Cache Miss Storm

Use CDN warmup and regional prefetching.

Stale Tiles

Use versioned tiles.

Example:

/tile/v45/z/x/y

Different Zoom Levels

Low zoom tiles can be heavily cached.

High zoom tiles need more detail.

---

B. Place Search Service

Responsibilities

• Search places by text and location

• Rank nearby results

• Support filters like open now, rating, category

• Handle spelling mistakes

Ranking Factors

• Text relevance

• Distance

• Popularity

• Rating

• Freshness

• Open now

• User history

• Business quality score
  

Flow

1. User searches “coffee near me”.

2. API Gateway sends request to Search Service.

3. Search Service queries Elasticsearch.

4. Geo-filter limits results by radius.

5. Ranking service re-ranks top candidates.

6. Response returns place cards.
   

Corner Cases

Duplicate Businesses

Use entity resolution.

Fake Listings

Use moderation and trust signals.

Closed Businesses

Need freshness pipeline from owners, users, and web crawl.

---

C. Geocoding Service

Responsibilities

• Convert address to coordinates

• Handle typos and abbreviations

• Support local address formats

Example

"MG Road Bangalore" → possible multiple matches

Return ranked candidates.

Components

• Address parser

• Normalizer

• Search index

• Geo ranker

• Confidence scorer

Corner Cases

Ambiguous Address

Return multiple candidates.

Rural Address

Use landmarks and approximate geocoding.

Wrong Pin Code

Use confidence score and fallback.

---

D. Reverse Geocoding Service

Responsibilities

• Convert lat/lng to address

• Find nearest road/building/area

• Determine locality/city/state/country

Components

• Spatial polygon index

• Road segment index

• Building footprint DB

• Admin boundary DB

Corner Cases

Middle of Highway

Return nearest road and direction.

Border Area

Need precise polygon containment.

Ocean / Empty Area

Return nearest known location or “unknown area”.

---

E. Routing Service

Responsibilities

• Compute fastest route

• Compute shortest route

• Avoid tolls/highways/ferries

• Support multiple transport modes

• Use traffic-adjusted edge weights

Road Graph

Vertices: intersections
Edges: road segments
Weights: travel time

Dynamic weight:

effectiveWeight = baseTravelTime + trafficDelay + turnPenalty + roadRestrictionPenalty

Routing Approach

For global scale:

• Partition graph by region

• Precompute shortcuts

• Use A* for local routing

• Use contraction hierarchies for long-distance routing

• Use traffic overlay for real-time delays

Corner Cases

Road Closure

Mark edge unavailable.

User Takes Wrong Turn

Navigation Service asks Routing Service for re-route.

Multi-Stop Route

Solve as constrained route optimization.

---

F. Navigation Service

Responsibilities

• Maintain active navigation session

• Receive user location pings

• Match GPS point to road

• Detect deviation from route

• Trigger re-routing

• Update ETA

Flow

1. User starts navigation.

2. Routing Service returns route.

3. Navigation session is created.

4. User sends location every few seconds.

5. Map-matching maps GPS point to road segment.

6. ETA is updated.

7. If user deviates, trigger re-routing.

Corner Cases

GPS Drift

Use map matching and smoothing.

Tunnel / Low Signal

Use dead reckoning based on last speed and heading.

Wrong Side of Road

Use heading and lane metadata.

---

G. Traffic Service

Responsibilities

• Ingest anonymous location pings

• Estimate speed per road segment

• Detect congestion

• Detect incidents

• Feed traffic data into Routing and ETA

Pipeline

Mobile Location Pings
→ Kafka/PubSub
→ Stream Processor
→ Map Matching
→ Segment Speed Aggregator
→ Traffic State Store
→ Routing Service

Data Stored Per Segment

{
  "segmentId": "s123",
  "avgSpeed": 18,
  "freeFlowSpeed": 55,
  "confidence": 0.91,
  "lastUpdated": 1710000000
}

Corner Cases

Sparse Data

Use historical traffic model.

Fake Traffic Attack

Ignore suspicious clustered signals.

Accident Detection

Detect sudden speed drops across multiple users.

---

H. Places / Business Profile Service

Responsibilities

• Store business details

• Let owners update information

• Validate ownership

• Store photos, opening hours, contact details
  

Data Model

{
  "placeId": "p123",
  "name": "ABC Cafe",
  "category": "CAFE",
  "location": {
    "lat": 28.61,
    "lng": 77.21
  },
  "address": "Connaught Place, Delhi",
  "openingHours": {},
  "phone": "+91...",
  "website": "https://..."
}

Corner Cases

Owner Conflict

Multiple people claim same business.

Spam Listing

Require verification.

Temporarily Closed

Support temporary status updates.

---

I. Reviews & Ratings Service

Responsibilities

• Store user reviews

• Calculate aggregate ratings

• Detect spam/fake reviews

• Support photos and review moderation
  

Flow

1. User posts review.

2. Review Service stores it.

3. Moderation pipeline checks abuse/spam.

4. Aggregation service updates rating.

5. Search ranking uses updated rating.

Corner Cases

Fake Reviews

Use trust score, device signals, account age, visit history.

Abusive Content

Moderation pipeline.

Review Bombing

Detect sudden abnormal rating spikes.

---

J. Offline Maps Service

Responsibilities

• Let users download regional map data

• Support offline search and basic routing

• Sync updates when online

Data Included

• Map tiles

• Road graph

• Basic places

• Address index

• Routing metadata

Corner Cases

Stale Offline Data

Show warning if map is old.

Low Storage

Allow selective download.

Offline Routing

Use local graph without live traffic.

---

8. End-to-End Flow

Flow 1: User Opens Map

1. App gets current location.

2. App calculates required tiles.

3. Tile requests go to CDN.

4. Tiles render on device.

5. Nearby labels and places load from Places Service.

---

Flow 2: User Searches “Petrol Pump Near Me”

1. Client calls Search API.

2. Search Service queries place index.

3. Geo-filter applies radius.

4. Ranking Service ranks by distance, rating, open status.

5. Results are returned.

6. Map shows markers.

---

Flow 3: User Starts Navigation

1. User selects destination.

2. Routing Service computes best route.

3. Navigation Service creates session.

4. Client starts sending location pings.

5. Traffic Service continuously updates road speeds.

6. Navigation Service updates ETA.

7. If user deviates, re-routing happens.

---

Flow 4: Real-Time Traffic Update

1. Many users send anonymized location pings.

2. Traffic pipeline map-matches pings to road segments.

3. Average speed is calculated per segment.

4. Congestion is detected.

5. Routing Service uses updated edge weights.

6. Users see updated ETA and traffic color.

---

9. Addressing NFRs

A. Scalability

Use:

• CDN for map tiles

• Regional sharding

• Kafka/PubSub for traffic ingestion

• Elasticsearch/OpenSearch for search

• Redis for hot traffic state

• Object storage for tiles/photos

• Cassandra/DynamoDB for high-write data

---

B. Low Latency

Critical paths:

• Tile load: CDN-backed

• Search: geo-index + cache

• Routing: precomputed graph shortcuts

• Traffic: Redis hot cache

• Navigation: local client-side smoothing + server updates

---

C. Reliability

Graceful degradation:

• If traffic service fails, use historical traffic.

• If routing service fails, use cached route.

• If search ranking fails, return basic search results.

• If CDN misses, fetch from origin.

---

D. Privacy

Location privacy is critical.

Use:

• Location anonymization

• Aggregation before traffic calculation

• Short retention for raw pings

• User consent for location sharing

• Encryption at rest and in transit

• Strict internal access controls

---

E. Observability

Track:

• Tile latency

• Search latency

• Routing latency

• ETA accuracy

• Traffic freshness

• Navigation re-route rate

• Geocoding success rate

• Crash rate

• Bad route reports

• Spam listings/reviews

---

10. Final Architecture Summary

Google Maps is a combination of:

• Massive read-heavy map tile system

• Geo-search engine

• Global road graph routing engine

• Real-time traffic ingestion pipeline

• Navigation session manager

• Places and reviews platform

• Privacy-first location processing system

The hardest parts are:

1. Real-time traffic at massive scale

2. Accurate ETA

3. Fast routing over global road graph

4. Fresh map and business data

5. Search ranking quality

6. Privacy-preserving location processing

A good interview answer should focus deeply on:

• Road graph modeling

• Tile serving via CDN

• Geo-indexing

• Routing algorithms

• Traffic pipeline

• Map matching

• ETA updates

• Re-routing

• Privacy and scale