Search⌘ K
AI Features

Google Maps API Design

Explore how to design the Google Maps API by understanding its key components, such as map tile delivery, route finding, navigation, and place search. Learn to apply architectural styles, protocols, and data formats to ensure low latency, scalability, and high availability in a real-world API scenario. Gain insights into the integration of REST, WebSockets, and HTTP/2 to support diverse client-server interactions and optimize user experience.

Google Maps API: Requirements and foundations

Google Maps provides travel-critical information: distance, ETA, optimal paths based on traffic, and turn-by-turn directions. Each capability maps to a distinct API surface. Designing these APIs requires understanding the backend system because an API reflects the underlying architecture. The design spans service workflows, endpoint definitions, request-response formats, and latency budgets.

Note: An optimal path is not always the shortest one, but rather the one that considers time, road closures, business needs, and real-world conditions.

Functional requirements

  • Map: Return map area snapshots based on user location and zoom level.

  • Route finder: Return optimal path(s) with distance and ETA based on source, destination, and transportation mode.

  • Navigation: Consume the user's GPS location in real time, guide decisions along the route, and continuously update ETA and distance.

  • Search place: Find and return information for a searched location or entity.

Functional and non-functional requirements of the Google Maps API
Functional and non-functional requirements of the Google Maps API

Nonfunctional requirements

  • Availability: High availability across all operations.

  • Accuracy: Optimal route(s) with accurate ETA.

  • Scalability: Handle large volumes of concurrent user requests.

  • Low latency: Real-time responses, with stringent requirements for navigation and relaxed tolerances for map tile retrieval.

Prerequisites

Two previously designed APIs serve as building blocks:

  • Search API: Enables place discovery on the map.

  • Pub-sub API: Handles inter-service communication (e.g., the navigation service triggers rerouting via pub-sub when a user deviates).

Design overview and decisions

With requirements established, the next step is selecting architectural styles, protocols, and data formats. The high-level architecture divides into three component categories:

  • Primary services: Client-facing services called via an API gateway that perform core functions: route finding, navigation, place search, and map tile delivery.

  • Persistence layer: Stores map tiles, road data, and analytics datasets.

  • Secondary services: Internal services (traffic analysis, data analytics) that support primary services. For example, analytics detects road closures from aggregated user locations and updates the maps service via pub-sub.

Note: Map tiles represent portions of the world map, each with a unique ID. The world map is divided into tiles based on zoom level and served from blob stores or CDNs to avoid transmitting the entire map.

The end-to-end-architecture of the Google Maps API
The end-to-end-architecture of the Google Maps API

The components and services involved in the Google Maps design are summarized in the following table:

Components and Services Details

Component or Service

Details

Maps service

  • Returns the map tiles link based on the user's location and zoom level

Places service

  • Returns the information related to the searched place


Route finder service

  • Takes start and destination points as an input
  • Returns the optimal route(s) to the user with ETA, distance, and steps for different transportation mediums
  • Suggests a new path if a user deviates from the suggested path



Navigation service

  • Periodically (say every 3–4 seconds) receives a user location from the client
  • Returns the updated ETA and distance while the user is moving on the path
  • Provides the users location to secondary services through the pub-sub service to update route and traffic information
  • Updates clients in case of any rerouting and road closures

Pub-sub service

  • Receives a location from the navigation service and sends this location to the secondary services
  • The secondary services notify the users via a navigation service about any change in the routes or maps


Data analytic service

  • Performs analytics on roads and traffic data
  • Helps maps and route finder service to return up-to-date map tiles information and accurate ETA on different conditions (such as traffic, road closure, etc.), respectively.

Traffic service

  • Analyzes the traffic condition through the history of the different location data of the users
  • Helps the route finder service in the estimation of an accurate ETA

API gateway

  • Authenticates the coming request
  • Throttles requests based on rate-limiting
  • Routes the requests to an appropriate service

Database

  • NoSQL database to store the road data
  • Relational DB for storing user information
  • Blob storage to store map tiles

Workflow

Four ...