Katkat
Back

Design a flight search platform

MetaSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a high-scale search platform that aggregates volatile data from heterogeneous third-party providers while maintaining low latency and high availability.

Problem Statement

Design a global flight search platform similar to Skyscanner or Google Flights. Users should be able to search for flights between two cities on specific dates, filter results by price, duration, and airline, and be redirected to a partner site to complete the booking.

Functional Requirements

  1. Search: Users can search for one-way or round-trip flights using origins, destinations, and dates.
  2. Filtering/Sorting: Results must be sortable by price and duration, and filterable by cabin class and stops.
  3. External Sync: The system must ingest inventory updates from hundreds of global airline and aggregator APIs.

Non-Functional Requirements

  1. Latency: Search results should return under 2 seconds, even if downstream providers are slow.
  2. Consistency: Prices displayed should be reasonably up-to-date, though minor discrepancies with final booking pages are acceptable.
  3. Scale: The system must support millions of concurrent daily active users and high-frequency updates from external providers.

Deliverables

  • High-level system architecture and data flow diagram.
  • API design (request/response models for searching).
  • Database schema and caching strategy to handle high-read volume.
  • Strategy for handling slow or unresponsive third-party flight APIs.

Example Scenario

  • Input: GET /search?origin=SFO&dest=JFK&date=2024-12-25&passengers=1
  • Output: A list of flight objects containing departure time, arrival time, price, airline, and a deep-link booking URL.

Hints

Hint 1

Consider the difference between a 'push' model (providers update you) and a 'pull' model (you poll providers) for inventory data.

Hint 2

Use a scatter-gather pattern to query multiple providers in parallel, but implement circuit breakers to prevent one slow API from hanging the entire request.

Hint 3

Think about how you would implement a distributed cache for pre-computed search results to handle frequent requests for popular routes.

Follow-up questions

  • How would you handle a situation where a provider's API experiences a massive spike in latency or downtime during a holiday booking period?
  • How would you design the system to handle 'phantom availability,' where a price is shown but is no longer valid by the time the user clicks 'book'?
  • How would you optimize the search for 'flexible dates' (e.g., +/- 3 days) without querying the backend for every possible combination?