Google Maps API Design Evaluation and Latency Budget
Explore the design and evaluation of Google Maps API, focusing on non-functional requirements such as availability, accuracy, scalability, and low latency. Understand how different services manage latency budgets using protocols like WebSocket and REST to deliver efficient real-time and map-related responses.
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