System Design: Airline Booking System

You are designing an airline booking platform that supports searching, booking, seat selection, and itinerary modification/cancellation. Assume consumer traffic is global, search is read-heavy, booking is write-critical, and seat inventory must not oversell.

Functional Scope

• Flight search: one-way, round-trip, multi-leg connections (max 2 stops), cabin filters, passenger types.
• Booking: create reservation, hold seats, payment, ticketing.
• Seat selection: seat map retrieval and seat assignment per segment.
• Modify/cancel: reprice and change flights, partial/whole cancellation, refunds.

APIs to Define

• Core REST and gRPC for: search, price/offer retrieval, book/confirm, modify, cancel, seat selection, fare-calendar (flexible dates).
• Idempotency handling for write operations.

Data Model to Specify

• Flights, legs/segments, fare classes and rules, seat inventory (by fare bucket and cabin), offers, reservations/PNR, tickets, payments, users, refunds.

Guarantees and Controls

• Ensuring seat availability and atomicity across connecting segments.
• Idempotency of booking/modify/cancel.
• Consistency guarantees (strong vs eventual) and concurrency control to prevent overbooking.
• Multi-region strategy: strong vs eventual consistency across regions.

Integrations

• Payments (authorize/capture/void/refund), ticketing issuance, notifications.

Search and Performance

• Indexing and caching for queries by origin, destination, dates, cabin; pagination, sorting; flexible-date search.

Scale and Resilience

• Scaling, sharding, read/write patterns.
• Resiliency: failover, retries, sagas/compensations.
• Observability and SLAs.

Multi-Tenancy and Partners

• Trade-offs: single-airline vs multi-tenant OTA scenarios.
• Partner API integration and rate limiting.

Deliver a coherent design covering the above, including minimal assumptions needed to make the system concrete.