Design a Flight Booking System
Design a flight booking system with seat inventory, double-booking prevention, dynamic pricing, and GDS integration.
Problem Statement
Design a flight booking system like Expedia that lets users search for flights, view seat availability across fare classes, book tickets with seat selection, and handle concurrent booking attempts without double-selling seats. Must integrate with airline Global Distribution Systems (GDS) and support dynamic pricing.
Requirements
Functional
- Search flights by origin, destination, dates, passenger count, and cabin class
- Display available fare classes with prices and remaining seat counts
- Book a flight: temporarily hold seats during payment, confirm or release
- Manage bookings: view itinerary, cancel/modify, check-in
Non-Functional
- Consistency: No double-booking -- seat sold to exactly one customer
- Latency: Search results in <3 seconds (aggregating from multiple airlines/GDS)
- Scale: 500M searches/day, 2M bookings/day, 5K concurrent booking attempts per popular route
- Availability: 99.95% for search, 99.99% for booking confirmation
Core Architecture
-
Flight Search Aggregator -- Fans out search requests to multiple airline GDS connections (Amadeus, Sabre, Travelport) and direct airline APIs in parallel. Merges results, deduplicates, and sorts by price/duration/stops. Caches search results for 15 minutes (prices change but not instantly) to reduce GDS query costs.
-
Seat Inventory Service -- Manages available seats per flight per fare class. Uses PostgreSQL with an optimistic locking pattern:
UPDATE seats SET booked = booked + 1 WHERE flight_id = ? AND fare_class = ? AND booked < capacity. If the UPDATE affects 0 rows, the fare class is sold out. For temporary holds, seats enter a HELD state with a 10-minute TTL, released automatically if payment is not completed. -
Booking Orchestrator -- Saga-based flow: (1) Hold seats in inventory, (2) Collect passenger details and payment, (3) Confirm with airline PNR (Passenger Name Record) creation, (4) Issue e-ticket, (5) Send confirmation. If airline confirmation fails, release hold and refund. Each step is idempotent with the booking reference as the idempotency key.
- Pricing Engine -- Airlines use revenue management (yield management) systems that adjust prices based on: days until departure, current load factor (% seats sold), competitor pricing, and demand forecasts. The booking system receives dynamic pricing from airlines and may add its own markup. Fare rules (refundable, changeable, baggage) vary by fare class.
Database Choice
PostgreSQL for bookings, passenger records, and seat inventory -- ACID transactions prevent double-booking. The seats table uses row-level locks during the hold phase. Redis for search result caching (keyed by route + dates + class, 15-min TTL) and temporary seat hold TTLs. Kafka for booking events consumed by email notification, loyalty points, and analytics services.
Key API Endpoints
GET /api/v1/flights/search?origin=SFO&dest=JFK&date=2024-06-15&passengers=2&class=economy
-> Returns: \{ flights: [\{ flight_id, airline, departure, arrival, duration, fare_classes: [\{ class: "Y", price: 299, seats_left: 12 \}] \}] \}
POST /api/v1/bookings
-> Body: \{ flight_id: "UA-123", fare_class: "Y", passengers: [\{ name, dob, passport \}], payment_method_id: "PM-7" \}
-> Returns: \{ booking_ref: "BK-456", pnr: "XYZ123", status: "CONFIRMED", e_ticket: "..." \}
DELETE /api/v1/bookings/\{booking_ref\}
-> Returns: \{ status: "CANCELLED", refund_amount: 249.00 \}
Scaling Insight
Temporary seat holds with TTL solve the concurrency problem elegantly. When a user selects a flight, seats are held for 10 minutes (not permanently reserved). This prevents the scenario where users abandon checkout with permanently locked seats. A background job releases expired holds every 30 seconds. This means the system can handle 5K concurrent booking attempts: most will get holds, some holds will expire and seats will be re-available, and only completed payments result in permanent bookings.
Key Tradeoffs
| Decision | Option A | Option B | Chosen |
|---|---|---|---|
| Seat inventory | Real-time GDS query per request | Cached + periodic sync | Cached with 15-min refresh -- GDS queries are expensive ($0.01+ each) and slow |
| Double-booking prevention | Distributed lock (Redis) | Database row-level lock | Database lock -- simpler, transactional, no distributed lock coordination needed |
| Hold duration | Short (5 min, more inventory churn) | Long (30 min, less churn) | 10 min -- balances user experience (enough time to enter payment) with inventory availability |
Practical Implementation for .NET Developers
In a .NET application, you would typically implement this pattern using the following approach:
ASP.NET Core setup: Create a service class that encapsulates the logic, register it with dependency injection, and inject it into your controllers or minimal API endpoints. The built-in DI container handles lifecycle management.
Entity Framework Core: For database interactions, EF Core provides the ORM layer. Use migrations for schema management and raw SQL for performance-critical queries. Consider Dapper for read-heavy paths where EF Core's overhead matters.
Azure integration: If deploying to Azure, leverage managed services — Azure Cache for Redis, Azure SQL, Azure Service Bus, Azure Cosmos DB. These eliminate operational overhead and provide built-in monitoring through Application Insights.
Testing: Use xUnit with Testcontainers for integration tests that spin up real databases in Docker. Mock external dependencies with NSubstitute. The WebApplicationFactory class lets you test your entire HTTP pipeline in-process.
Monitoring: Add Application Insights telemetry to track request latency, dependency calls, and custom metrics. Use structured logging with Serilog to make production debugging possible:
Log.Information("Processing order {OrderId} for {CustomerId}", orderId, customerId);
This gives you searchable, structured logs in Azure Monitor or Seq.
System-Specific Clarifying Questions
Before designing Flight Booking, ask questions specific to THIS system:
- Who are the primary users? Understanding the user base shapes every technical decision — consumer apps have different requirements than enterprise B2B systems.
- What is the read-to-write ratio? This determines whether you optimize for fast reads (caching, denormalization) or fast writes (write-ahead logs, async processing).
- What is the geographic distribution? Users in one country vs. global users fundamentally changes your data replication and CDN strategy.
- What is the acceptable latency? Some features need sub-100ms responses, others can tolerate seconds. This determines your caching and architecture strategy.
- What is the consistency requirement? Some data (payments, inventory) needs strong consistency. Other data (social feeds, recommendations) can be eventually consistent.
Architecture Deep Dive
The architecture for Flight Booking should be designed around the specific access patterns of the system. Do not apply generic templates — every system has unique hotspots, bottlenecks, and scaling challenges.
Write Path: How does data enter the system? Is it bursty (event-driven, flash sales) or steady (sensor data, logs)? Bursty writes need queuing and backpressure. Steady writes can go directly to the database.
Read Path: How is data consumed? Is it fan-out (one write, many reads like social feeds) or point lookups (one read for specific data like user profiles)? Fan-out reads benefit from pre-computation and caching. Point lookups benefit from efficient indexing.
Hot Spots: Where are the bottlenecks? For Flight Booking, identify the component that will fail first under load and design mitigation strategies: caching, sharding, rate limiting, or async processing.