How the interviewer opens it
“Design a service that collects travel confirmations and organizes them into itineraries. Travelers should see a clear plan when providers send duplicate confirmations or change their bookings.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Input sources
- Scale and traffic mix
- Message size and retention
- Booking identity
- Changes and user edits
- Dates and time zones
- Trip membership
- Latency
- Consistency, durability, and access
- Exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Import flight, hotel, and car rental confirmations.
- Reconcile duplicate confirmations, changes, and cancellations.
- Group bookings into trips and show the correct local dates and times.
- Let users correct booking details and move bookings between trips.
Usually out of scope
- Ticket purchases, payments, and refunds.
- Live flight status.
- Mailbox sync and attachment extraction.
- Travel recommendations.
What interviewers ask about
- Booking identity
- Different references can describe one booking. Similar dates and routes can also describe separate purchases.
- Changes from providers
- Providers send late or conflicting facts without a shared revision sequence. User corrections create another source of authority.
- Dates and local times
- Travel spans local calendars, ambiguous clock times, and dates without times. One UTC timestamp cannot represent every source fact.
- Trip membership
- Dates and locations suggest a trip but do not prove its boundaries. Later imports must respect user choices.
Common mistakes
- Treats repeated message detection as the complete solution to booking identity.
- Uses the latest receipt time as the latest booking state.
- Uses a provider reference as a permanent global identifier.
- Stores only UTC or converts date-only values into midnight timestamps.
- Lets provider imports erase user corrections or trip choices.
- Adds distributed infrastructure before defining identity, source authority, and recovery rules.
The bar by level
- Senior (L5/E5)
- Separates delivery identity from booking identity. Handles conflicting updates, concurrent workers, user corrections, and ambiguous times. Explains transactions and recovery.
- Staff (L6+/E6+)
- Defines policies for uncertain identity and source authority. Supports reversible merges and controlled replay. Explains how policy changes affect existing trips and recovery.