Engineering a 100 ms Google Maps Load: Latency Budget, On-Device Caching and Edge Serving

Design the architecture that lets Google Maps load in under 100 ms. Explain where the time goes between a user opening Maps and seeing a usable map, and what you would change on the device, in the network path and on the servers to meet the target. ```hint Spend the budget on paper first Split the 100 ms into the steps between the tap and a visible map, then ask which of those steps can afford to wait on a network at all. ``` ### Clarifying Questions - What counts as "loaded": the base map of the user's current area only, or also their location, live traffic and search results? - Is the target for the mobile apps, the web version or both, and for a warm start of an installed app or a first-ever launch? - At which percentile should the target hold, and does it include users on slow mobile networks and low-end phones far from any data center? ### What a Strong Answer Covers - Turning "load" into a measurable metric with a starting event, a platform and a percentile - A latency budget grounded in network round-trip times, payload sizes and on-device rendering cost - Client-side techniques that take the network off the critical path, and what they cost in storage, freshness and battery - Server and edge design for the data that must still travel over the network: tile delivery, caching layers and regional serving - How the product manager would measure the result, roll it out, and decide which user segments get which trade-offs ### Follow-up Questions - Which parts of Maps can never be served entirely from the phone, and how do you keep them from blocking the first view? - On a low-end phone with little free storage, what would you cache and what would you drop? - How would you test whether users actually notice the difference between a 100 ms load and a 300 ms load?