Design automatic travel insurance enrollment triggered by customer location

Design the backend for a mobile banking app feature that enrolls customers in travel insurance automatically, based on where they are. A customer opts in once. From then on, when the system detects that they are in another country, it starts insurance coverage for them without any action on their part, keeps it active while they are abroad, and stops it when they return home. This is a classic system design discussion. Expect the interviewer to focus on event-driven processing and on how your databases scale for both reads and writes. For practice, take this baseline as given and confirm it with the interviewer: - The app can report the device's location, and in-person card payments reveal the merchant's country. - An insurance provider, internal or a partner, creates and ends policies through an API. - Pricing and billing rules belong to the product team; ask about them rather than inventing them. ### Clarifying Questions - Which signals count as evidence that a customer is abroad, and how far should a single signal be trusted on its own? - Should coverage start on the first signal, or only after confirmation, to avoid triggering near a border, during airport transit, or from a VPN? - How is coverage charged: per day abroad, per trip, or as part of a subscription? - Is one-time consent enough, or must the customer confirm each trip? Can they end coverage manually? - Are any destinations excluded from coverage? - How many customers are opted in, and how often does the app report location? ### Part 1 — Requirements, enrollment rules and estimates Pin down the functional and non-functional requirements, the rules that decide when a trip starts, changes country and ends, and rough traffic and storage estimates. ```hint Find the hot path Compare how often location reports arrive with how often trips actually start; the gap tells you which part of the system has to scale. ``` #### What This Part Should Cover - Trip start, country-change and end rules, with false positives addressed - Different consistency and latency needs for coverage records versus location tracking - Estimates that show where the volume concentrates ### Part 2 — Event-driven flow from signal to active coverage Lay out the components and events from the moment a location signal arrives to a confirmed policy, a customer notification and a charge. Show the APIs the app calls. ```hint Order per customer Consider what goes wrong if two signals for the same customer are processed out of order, or by two workers at the same time. ``` #### What This Part Should Cover - Ingestion and normalization of signals from more than one source - Per-customer presence tracking and the events it emits - Enrollment with the insurer, billing and notification as decoupled consumers ### Part 3 — Data model, scaling and failure handling Define the main records, explain how reads and writes scale for each store, and walk through failures: duplicate or late events, a crash in the middle of enrollment, an insurer outage, and a trip with almost no location signals. ```hint Make every effect repeatable For each side effect, ask what stops it from happening twice when a message is delivered again. ``` #### What This Part Should Cover - A data model that separates high-volume signals from authoritative policy and billing records - Read and write scaling choices matched to each access pattern - Idempotency, retries and reconciliation for each failure listed ### What a Strong Answer Covers - A precise definition of when coverage starts and ends, including ambiguous cases - An event-driven pipeline with per-customer ordering and decoupled consumers - Exactly-once business effects built on at-least-once messaging - Storage choices matched to access patterns, with read and write paths scaled separately - Privacy of location data, an audit trail for claims, and observability of activation delay ### Follow-up Questions - A customer's phone is off for the whole trip, but their card is used in shops abroad. How do they still get covered, and from which date? - The insurer's API is down for an hour at the start of a holiday weekend. What happens to new enrollments and to what customers see? - During a claim dispute, how do you prove that a customer was covered on a specific day? - How would you handle destinations that become excluded from coverage while customers are already there?