...
/Evaluations of Nonfunctional Requirements of Google Maps
Evaluations of Nonfunctional Requirements of Google Maps
Evaluate key nonfunctional requirements and understand the trade-offs and optimizations for a system like Google Maps.
Following the system’s architecture and API design, a crucial engineering phase is evaluating its nonfunctional requirements (NFRs). These requirements define the system’s quality and usability, addressing key aspects such as performance, efficiency, and accessibility. For a mapping application, NFRs are central to the service’s core value and user trust.
In this lesson, we will analyze the key NFRs that shape a system like Google Maps. We’ll explore the specific engineering techniques used to meet these demands, and the inevitable trade-offs in balancing competing goals.
We begin with the user’s ability to access the service, regardless of location or network condition.
Availability and offline access
For a mapping app, availability means remaining functional and useful even when the network is unreliable or completely offline. This is about the client’s resilience, achieved by managing a data life cycle with three distinct modes: online, offline, and resynchronization. The diagram below illustrates this entire process:
Let’s break down the key strategies that enable this life cycle.
Graceful degradation: The mobile app must be designed to handle partial service failures intelligently. For example, if the service that provides live traffic data is unreachable, the app should gracefully degrade. It should do this by hiding the traffic layer and continuing to provide core routing and map functionality with the data it does have.
Note: Designing for graceful degradation ensures that minor backend or network failures do not derail the user experience.
On-demand caching: The app automatically stores downloaded map tiles in a local cache as the user browses for short-term connection drops. If the user loses connection and revisits that area, the map will still render using these cached tiles.
Note: This opportunistic caching is great for casual use but is unreliable for planned offline trips.
Bulk region downloads: The app allows users to proactively download entire map regions for guaranteed offline use. When the device is offline, the app’s data layer redirects all requests for maps and routing to this local database.
Note: The trade-off is that offline maps can consume gigabytes of storage, and the initial download can be slow and data-intensive.
This table summarizes the trade-offs for the reliability techniques discussed:
Technique | Primary Benefit | Key Engineering Challenge |
Graceful degradation | Core functionality remains operational during partial service failures. | Increased complexity in client-side error handling and state management. |
On-demand caching | Masks transient network failures for recently viewed areas. | Unreliable for planned trips; cache size is limited. |
Bulk region downloads | Guarantees offline access to maps and routing for a specific area. | Consumes significant device storage; initial download is slow. |
A user has downloaded an offline map for “Downtown.” Their calculated route, however, takes them one mile outside this downloaded area into a region where they will have no network service. What should the app do as the user approaches the edge of their offline map? What are the UX trade-offs between the possible strategies?
Once the system is ...