“Design a travel booking app” combines search at scale, payment, complex itinerary management, and the unforgiving UX of “I am at the airport and need my boarding pass.” Expedia, Kayak, Hopper, Booking.com, Airbnb, Google Flights are the references. The interview tests how you decompose this into manageable subsystems.
Clarify scope
- Flights, hotels, cars, activities — which?
- OTA (online travel agency) selling inventory, or metasearch (redirect to provider)?
- Logged-in trips and itinerary management?
- Loyalty program integration?
- Boarding passes / digital travel docs?
Core flows
- Search: airport, dates, passengers
- Results: filter, sort, compare
- Detail: review fare rules, baggage, seat selection
- Book: passenger info, payment, confirmation
- Trip: itinerary, check-in, boarding pass, notifications
- Post-trip: review, rebook, support
Search architecture
Flight search is one of the most expensive query types in tech:
- For a single OD pair, dozens to hundreds of fares from many GDS providers
- Server fans out queries; aggregates and caches
- Cache key (origin, destination, date) with TTL — fares stale within minutes
- Streaming results: show first batch fast, append more as they arrive
Filter and sort UI
- Stops, airline, time of day, duration, price range
- Update results in place as filters change (debounce)
- “Cheapest” / “Best” / “Fastest” sort tabs at the top
- Persist filters across sessions per user
Booking flow
- Multi-step form: passengers, contact, seat, payment
- Auto-fill from saved profiles (passport, frequent-flyer, payment cards)
- Apple Pay / Google Pay first-class
- 3DS / SCA handling — heavy in EU
- Optimistic UI with clear “We are processing your booking” state
- Idempotency keys to prevent double-booking on retry
Itinerary management
The itinerary is the home for a confirmed trip:
- All segments (outbound, inbound, hotels, transfers)
- PNRs, confirmation codes
- Live status (delayed, cancelled, on-time)
- Check-in CTAs at the right time
- Boarding passes (Apple Wallet / Google Wallet integration)
Boarding pass — the airport-critical screen
- Cached locally so it works without signal
- Apple Wallet pass with PKPASS format; Google Wallet equivalent
- Barcode visible without unlocking the phone (iOS Lock Screen / Dynamic Island)
- Real-time updates: gate change, seat change, time change
- Live Activity for active flights showing time-to-boarding
Notifications
- Pre-trip: 24 hours before, time to check in
- Day of: gate, terminal, time, security wait
- In-flight transition: “you have arrived; here is your hotel info”
- Disruption: “your flight is delayed; here are alternatives”
- Post-trip: review prompt, rebook for next trip
Offline experience
- Itinerary and boarding passes always available offline
- Cached map of the airport for navigation
- Hotel address and check-in details cached
- Search and booking require connectivity (acceptable)
Map integration
- Hotel detail shows location with surrounding context
- Airport terminal map for layovers
- Walking directions to gate or hotel
Loyalty programs
- Frequent-flyer numbers stored per traveler
- Auto-attach to bookings
- Earned miles surfaced after booking and after travel
- Status display: bronze/silver/gold per program
Currency and locale
- Display prices in user-preferred currency
- Backend stores in a single currency (often USD); convert at presentation
- Locale-aware date and time
- Timezone-aware itinerary display (departure in one TZ, arrival in another)
Customer support integration
- One-tap from itinerary to chat
- Context preserved (current trip, current segment)
- Escalation to phone for urgent issues
- Self-serve options: change flight, cancel, request refund
What separates senior from staff
Senior candidates handle the search-fanout caching and itinerary state. Staff candidates discuss the boarding-pass-must-work-offline constraint, idempotency in booking, the timezone-aware trip display, and the disruption-handling flow. Principal candidates raise the regulatory side (DOT 24-hour cancellation, EU Regulation 261, GDPR for traveler data).
Frequently Asked Questions
Why is flight search so slow?
Many sources, varying API quality, real fare-rule complexity. Caching helps; the fundamental cost is querying many GDS providers in parallel. Streaming results is the standard mitigation.
How do I handle GDS-side errors during booking?
Use idempotency keys; design the flow so a retry does not double-book. Surface clear errors to the user; offer a quick path to support.
What about AI-driven trip planning?
Coming, not standard yet. Hopper and Google have AI-assisted itinerary generation; the interview question rarely requires you to design that, but mention it as a forward-looking feature.