Katkat
Back

Consolidate Three Partner APIs into a Query Service

ExpediaSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This problem tests your ability to design a robust middleware layer that abstracts heterogeneous downstream APIs into a unified, reliable, and performant service.

Problem Statement

Design a Query Service that aggregates data from three distinct third-party travel partners (Partner A, B, and C). Each partner provides hotel availability data but uses different response schemas, pagination mechanisms (e.g., cursor-based vs. offset-based), and rate limits.

Requirements

  1. Functional: Create a unified API endpoint that accepts a location and date range, returns a normalized list of hotel options, and handles partial failures (e.g., if one partner times out, return results from the other two).
  2. Non-Functional:
    • Resilience: Implement circuit breakers and retries to handle unstable upstream endpoints.
    • Normalization: Define a strategy to map disparate schemas into a canonical domain model.
    • Observability: Track latency, error rates, and data freshness per partner.
    • Identity Resolution: Provide a mechanism to deduplicate identical hotel entries across different partners.

Scale Assumptions

  • Expected peak traffic: 5,000 requests per second (RPS).
  • Downstream latency: Partners range from 200ms to 2s per request.
  • Partner quotas: Strict limits on concurrent connections per partner.

Deliverables

  • Sketch the high-level system architecture.
  • Define the data model for the canonical representation.
  • Explain how you handle the "Partial Result" scenario (returning data even if one provider fails).
  • Describe the data pipeline for resolving entity identity (e.g., matching a hotel name/address across partners).

Hints

Hint 1

Use an Adapter pattern to decouple the service core from the specific integration logic of each partner.

Hint 2

Implement a dedicated Cache layer (e.g., Redis) to store normalized data, reducing the need for constant downstream calls.

Hint 3

Utilize an asynchronous aggregation pattern where the service waits for a predefined timeout before returning whatever results were gathered.

Follow-up questions

  • How would you handle a scenario where one partner updates their API schema, causing widespread normalization errors?
  • If we need to perform a backfill or re-index data, how would you ensure the system remains available for user queries?
  • How would you modify the design to support 10 additional partners without increasing the operational burden linearly?