Katkat
Back

Design automatic travel insurance enrollment triggered by customer location

RevolutSoftware Engineer · Other
MediumSoftware EngineerOtherSystem Design

Last updated

A system design exercise for a banking app that automatically enrolls opted-in customers in travel insurance when location signals show they are abroad. It tests requirements scoping, an event-driven pipeline, idempotent enrollment with an insurer, data modeling, scaling reads and writes, and failure handling.

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.

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.

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.

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

Hints

Hint 1

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.

Hint 2

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.

Hint 3

Make every effect repeatable: For each side effect, ask what stops it from happening twice when a message is delivered again.

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?