Google Maps API Design Decisions

Designing an API for a mapping service is complex due to the numerous components operating under the surface. This involves several decisions, such as selecting an architectural style, a protocol, and the data formats to be used in communication between the different entities. In this lesson, we will discuss the end-to-end workflow and the design considerations for our Google Maps API.

Design overview

The following illustration depicts a high-level architecture for Google Maps based on our functional requirements. We can divide the components involved in the architecture into the following categories:

• Primary services: These services should be directly called by the different clients via an API gateway. They mainly perform the core functionalities, such as finding optimal routes, navigation directions, searching places, and so on.

• Persistence layer: The persistence layer stores data such as map tiles and road data. Later, this data is useful in performing analytics to improve the overall experience of the Google Maps service.

• Secondary services: These services work within the organization and help primary services to achieve their functionalities. For example, traffic and data analytics services help the route finder service to calculate the estimated time of arrival (ETA) at the destination. Also, the data analytics service analyzes the road closure situation from the different user locations and updates the maps service via a pub-sub.

Note: The map tiles represent a portion of the world map. Each map tile has a unique ID. Since sending a complete map uses unnecessary bandwidth and causes a delay, we divide the world map into tiles based on the zoom level. These tiles are kept in blob stores or served from CDNs.