Google Maps Live Location Sharing: Architecture for Freshness, Battery and Privacy

You are a product manager on Google Maps, and the interviewer wants to see how well you understand the engineering behind location sharing: the feature that lets a person share their live position with people they choose, who then see it move on their own map. Explain how you would design the technical side of this feature. ```hint Follow one update Trace a single location reading from the sharer's phone to a viewer's screen. At each hop, ask what it costs in battery or servers and who is allowed to see it. ``` ### Clarifying Questions - Who can see a shared location: only specific contacts the sharer picks, anyone holding a link, or both? - Does sharing last for a set duration, until the sharer turns it off, or either? - How fresh must the position look to a viewer, and how much battery drain is acceptable on the sharer's phone? - Should the system keep a history of past positions, or only the latest one? ### What a Strong Answer Covers - An end-to-end flow covering the sharer's device, the upload, storage of the latest position, and delivery to viewers. - A data model for who may see whom, including duration, expiry and revocation, kept separate from the stream of positions. - The trade-off between freshness, battery life and server cost, and how the update frequency would be controlled. - Privacy and safety: consent, visible indicators, fast revocation and data retention. - Rough scale estimates, failure handling such as a phone going offline, and how the team would monitor the feature. ### Follow-up Questions - A sharer stops sharing while a viewer has the map open. How do you make sure the viewer stops seeing updates within seconds? - How would the design change if positions had to be end-to-end encrypted so that the servers cannot read them? - Users report that a friend's location looks stuck. How would you find out whether the cause is the phone, the network or the backend?