How the interviewer opens it
“Design an airline reservation service. Travelers search flights and reserve seats on trips with one or more flight segments. The service must not sell a seat twice.”
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
- Ownership and scope
- Flight scale
- Traffic and read:write mix
- Itinerary rules
- Search and fares
- Temporary holds
- Payments
- Latency
- Consistency and availability
- Durability and location
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
- Search for direct and connecting flights
- Create a temporary hold for every requested seat in an itinerary
- Confirm the entire itinerary without duplicate seat sales
- Return the reservation state after retries or payment delays
Usually out of scope
- Reservations with other airlines
- Dynamic fares and revenue management
- External ticket issuance
- Loyalty programs
- Active service across multiple regions
What interviewers ask about
- One reservation across several flights
- One trip consumes seats on several flights. Shared flight segments create contention between otherwise different itineraries.
- Seat holds at the deadline
- Expiry races with confirmation and new holds. Work from an old hold must not release a seat that a new customer owns.
- Payment delays and reservation state
- The payment provider and inventory database cannot commit together. An uncertain payment result must not cause a second charge or seat sale.
- Flight search and seat availability
- Search must combine flight schedules quickly. Its availability view changes while many travelers compete for the same connecting flight.
Common mistakes
- The design treats each flight as an independent purchase and permits partial itineraries.
- The design confuses a recurring flight number with a dated flight instance.
- The service trusts search availability when it creates a hold.
- The service returns availability older than five seconds after search updates stop.
- The design depends on timely cleanup to enforce hold expiry.
- The service releases seats after a payment timeout without a definite payment outcome.
The bar by level
- Senior (L5/E5)
- The candidate defines lock order, deadline checks, and idempotent retries. The design handles old hold work and uncertain payments. Search enforces the freshness limit.
- Staff (L6+/E6+)
- The candidate defines ownership during database failover and payment uncertainty. The candidate explains when inventory must split across databases. The candidate revises guarantees for external airlines and states explicit availability limits.