# Design a Mobile Travel Itinerary App Source: https://www.techinterview.org/post/3233475168/design-mobile-travel-itinerary-app/ Updated: 2026-07-26 · techinterview.org Travel itinerary apps (TripIt, Hopper, Google Trips legacy) auto-organize a trip from confirmation emails into a unified itinerary. [The interview](/system-design-interview-guides/) tests whether you understand email parsing, time-zone-aware data modeling, real-time flight tracking, and the operational realities of a stressed traveler at an airport. ## Functional requirements - Forward email confirmations; app extracts trip details - Unified timeline of flights, hotels, rentals, restaurants - Time-zone aware: shows arrival in destination time - Real-time flight status (delays, gate changes) - Offline maps and notes for destinations - Sharing with travel companions ## Email parsing Source of trip data: confirmation emails forwarded by the user. Parsing strategies: - Pattern matching for known senders (United, Delta, Hilton): regex or template extractors keyed to each sender's HTML layout. Fast and accurate for the handful of airlines and chains that cover most volume, but they break the moment a sender tweaks their template, so budget for ongoing maintenance. - Generic ML model for unknown formats: a trained extractor pulls dates, times, confirmation numbers, and locations from senders you have no template for. Precision is lower than a hand-built template, so route low-confidence extractions to review instead of silently creating a wrong event. - Schema.org structured data when available: many confirmation emails embed machine-readable markup (schema.org/FlightReservation, LodgingReservation) as JSON-LD. When it's present it's the cleanest source — parse it first and fall back to text extraction only when it's missing. Modern apps increasingly use LLMs for robust parsing across diverse email formats. ## Time-zone modeling The most-broken aspect of travel apps. Each event has: - Local start/end time: store the wall-clock time the traveler actually experiences, not just a UTC instant. A 9:00am departure should read 9:00am regardless of where the device or server sits. - Time zone (IANA identifier): keep the IANA zone (America/New_York, Asia/Tokyo) with each event, never a fixed offset — offsets shift with daylight saving, so a stored offset goes stale across a DST boundary. Zone plus local time lets you compute UTC on demand for sorting and countdowns. - Logical "trip day" for organizing: group events into "Day 1, Day 2" by the destination's local calendar so an overnight red-eye lands on the right day. A classic interview probe is the flight that departs late one night and arrives the next morning across zones. Critical: a 1pm Tokyo arrival is at midnight in NYC. The display must show local-to-the-event time, not user's home time. ## Real-time flight tracking Sources: - FlightAware, FlightStats, OAG (commercial APIs): these feeds carry schedules, live status, gate, and delay data. Pricing is usually per-query or tiered, so cache aggressively and only poll flights inside an active window — roughly the day of travel — rather than every flight in every stored itinerary. - Airline-specific APIs (limited public access): a few carriers expose direct APIs, often gated behind a partnership. Coverage is uneven, so treat these as a supplement to a commercial aggregator instead of the primary source. Push notifications for: - Schedule change: the highest-value alert — a departure moved by hours. Fire it the moment the feed reports the new time so the traveler still has room to rebook. - Gate change: common and easy to miss on airport boards. Include both the old and new gate so the message is actionable at a glance. - Boarding: time-sensitive; deliver as boarding starts. Some travelers lean on this instead of listening for gate announcements. - Departure / arrival: confirms the leg happened and lets whoever is meeting the traveler track progress. The arrival push is also a good trigger to flip the display to destination-local time. Critical that these are reliable — travelers count on the app. ## Offline maps and notes For destinations without reliable cellular: - Pre-download maps (OpenStreetMap or Google offline maps): bundle a map region for each destination while the user still has wifi. OpenStreetMap tiles can be self-hosted; Google's offline maps carry licensing limits worth checking before you commit. - Cache key destinations: hotel address, restaurant reservations: store the geocoded hotel and reservation locations so the traveler can pull up an address and navigate with no signal. - Cache trip docs (boarding pass PDFs, hotel confirmations): keep these on-device — the moment you most need a boarding pass is often the moment you have zero bars. ## Wallet integration Boarding passes go in the user's mobile wallet: - Apple Wallet: PKPass format: boarding passes ship as signed .pkpass bundles, so your server needs the pass type ID and signing certificate to generate or update them. The payoff is lock-screen and geofenced surfacing right at the airport. - Google Wallet: Wallet API: passes are created server-side and added through a save link or JWT. Both platforms support push updates, so a gate change can update the pass in the wallet itself, not only inside your app. App can generate or import these from email attachments. ## Sharing Travel companions need access: - Read-only sharing via link or in-app invite: the common case — a companion sees the itinerary but can't change it. A shareable link is easiest; an in-app invite ties access to an account so you can revoke it later. - Full collaboration: anyone can edit, which raises concurrent-edit and conflict questions — the same territory as [collaborative editing](/post/3233460997/system-design-collaborative-editing/), so be ready to talk about last-write-wins versus merging. - Per-event sharing (only the joint dinner, not the whole trip): share a single reservation without exposing the full itinerary. Model access at the event level, not just the trip level, or this case gets awkward. ## Calendar integration Sync trip events to user's calendar: - iOS: EventKit: write events straight into the user's calendar after requesting calendar permission. Keep a stable external identifier per event so a re-sync updates the existing entry instead of duplicating it. - Android: Calendar Provider: the Calendar Provider content API fills the same role on Android — you insert events against a chosen calendar account. - Cross-platform: ICS export: an .ics file works everywhere with no per-platform integration, which makes it a solid fallback and easy to share. The catch is it's a one-way snapshot, so later changes won't propagate. ## Battery and data Light. Travel apps are reference apps, not always-on. The exception: real-time flight tracking pushes are infrequent but high-value. ## Frequently Asked Questions ### What if the user forwards an email in a non-supported language? Modern LLM-based parsers handle most languages. Older pattern-matching parsers fail; surface the email to manual review. ### How does the app handle a multi-leg flight? Each leg as separate event. Display as a connected itinerary. Track delays per leg. ### What about loyalty programs? Connect to airline/hotel accounts; track points and tier progress. OAuth is the norm.