Evaluation of Google Maps' Design

Let’s see how the system we designed will handle millions of queries per second, ensuring a fast response time.

Availability

With a large road network graph hosted on a single server, we ran into these issues:

• We couldn’t process user queries, since it was impossible to load such a large graph into the memory, making the system unavailable to the users.
• It wasn’t possible to make a persistent two-way connection (for navigation) between the server and millions of users per second.
• It was also a single point of failure.

We solved the above problems by dividing the world into small segments. Each small segment consists of a graph that can be easily loaded into a server’s memory. With segments, we completed these objectives:

• We hosted each segment on a separate server, mitigating the issue of loading a large, global graph.
• The load balancer divides the request load across different segment servers depending on the user’s area of search. It mitigates the issue of putting the burden on a single server, which was affecting the system’s availability.
• We didn’t discuss replication, but we can replicate each segment, which will help deal with a segment server as a single point of failure and distribute the request load for a segment to replicas.

Note: Google Maps uses lazy loadingLazy loading is postponing the loading or initialization of resources or objects until they are needed. It reduces initial load time by reducing the amount of content to load, saves bandwidth by delivering content to users when required, and preserves server and client resources by rendering only some of the content. Thus, it increases performance and saves system resources. of data, putting less burden on the system, which improves availability.

Lazy loading reduces initial load time by reducing the amount of content to load, saves bandwidth by delivering content to users when needed, and preserves server and client resources by rendering only some of the content.