Design a panic-alert system that, when a user signals danger, delivers their live location fast and reliably to their personal contacts, to nearby responders, and to the authorities, and keeps updating that location as they move.
Design the backend for a personal-safety application. In normal use the app is quiet, but when a user is in danger they trigger an alert, for example by holding a panic button. The moment that happens, the system must do two things at once and do them reliably: it must push the user's current location to several very different kinds of recipient, and it must keep pushing updated locations as the user keeps moving, until the situation is resolved.
The recipients are not one audience but three. First, the user's own trusted contacts, such as family, who were configured ahead of time. Second, responders and other app users who are physically near the user right now, which the system has to work out at the moment of the alert by searching for who is within some radius of the user's location. Third, the responsible authorities, such as a police dispatch endpoint. A single alert therefore fans out to a personal list, to a location-derived set of nearby parties, and to an institutional endpoint, and every one of those deliveries matters because a dropped alert in this system is a safety failure, not an inconvenience.
Two forces shape the design. Delivery must be reliable and decoupled: the act of triggering an alert must be acknowledged instantly and must not be blocked by the slowness or temporary failure of any single downstream channel, so the trigger enqueues the fan-out work and lets consumers deliver to each channel independently and retry failures. And the nearby lookup must be fast: finding who is within range of a moving person is a proximity query over live locations, which needs a store built for spatial lookups rather than a scan of an ordinary table. Meanwhile locations stream in continuously from users so that "where is this person now" is always current.
Lay out the architecture: how the trigger enters and is acknowledged, how the fan-out to the three recipient classes is made reliable, how nearby parties are found, where live locations and the durable record of contacts and alerts live, and how the read path stays fast. Then document the API the app calls, and the trade-offs, including delivery guarantees and the cost of getting an alert to everyone who needs it.