Google Maps API Design Evaluation and Latency Budget

Introduction

We've discussed the design considerations and API model for each functional requirement. In this lesson, we'll cover the approaches for achieving our non-functional requirements and estimate the response time of our Google Maps services.

Non-functional requirements

Let's discuss how we achieve the non-functional requirements for our APIs one by one.

Availability

We ensure the availability of our service by replicating our Google Maps services (such as maps, route finder, and places). For example, if a service is not available in one region, the API gateway can route the request to the available replica of this service in another region. Furthermore, if the server is not compatible with the WebSocket while upgrading, we fall back to HTTP/2. It is a trade-off between availability and low latency, but low latency is bearable when it is instead of unavailability of the service.

Accuracy

The accuracy of the results depends on the accuracy of the client's location, so the GPS should be turned on while using the Google Maps service. It also depends on the backend algorithms (such as Dijkstra's and A* algorithms) of the route-finding service to find the optimal path. Apart from algorithms, technologies like machine learning (ML) play a vital role in finding the best routes. For example, if a frequently used route is suddenly avoided by Google Maps users, the service can intelligently guess that there is a temporary route closure and suggest alternate routes. Another critical factor that improves the accuracy of the service is crowd-sourced traffic informationCrowdsourcing. The ETA is improved by performing analytics on the user's data and finding patterns to detect any anomaly on the routes and, subsequently, adjusting the ETA calculation.

Scalability

The stateless nature of the HTTP allows our service to scale easily. Because each request is independent, it’s easy for the API gateway ...