---
title: "Multi-Supplier Hotel Search Architecture"
description: "Design hotel search across multiple suppliers using fan-out, normalization, deduplication, timeout budgets, partial results and ranking."
slug: "multi-supplier-hotel-search-architecture"
translationKey: "architecture-multi-supplier-hotel-search"
locale: "en"
type: "guide"
category: "architecture"
tags: ["hotel","architecture","supplier","fan-out","normalization"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

Multi-supplier hotel search is not simply sending the same request in parallel. The real problem is converting **different identity, rate, latency and failure contracts into one traveler-facing search contract**.

## Production scenario

One hotel/date/occupancy search fans out to three suppliers and one direct channel. Some providers return in 300 ms, others in 2 seconds; the same property has different IDs and tax/fee semantics.

## Architecture flow

```mermaid
%% title: Multi-supplier hotel search flow
%% description: A search request moves through canonicalization, supplier fan-out, normalization, mapping, deduplication and ranking.
flowchart LR
  A[Search Request] --> B[Request Canonicalization]
  B --> C[Supplier Eligibility]
  C --> D{Parallel Fan-out}
  D --> E[Supplier Adapter A]
  D --> F[Supplier Adapter B]
  E --> G[Adapter Normalize]
  F --> G
  G --> H[Property Mapping]
  H --> I[Offer Fingerprint / Dedup]
  I --> J[Price & Policy Normalize]
  J --> K[Ranking]
  K --> L[Partial / Final Response]
```

## Key entities

Use explicit SearchContext, CanonicalProperty, SupplierPropertyRef, RawOffer, NormalizedOffer, OfferFingerprint, ProviderHealth and SearchExecution models.

Do not expose supplier DTOs directly to the UI.

## Design decisions

Calling every supplier maximizes coverage but increases latency and cost. Eligibility should consider market, coverage, quota and provider health.

Normalization should create a common model while preserving source IDs and raw context for later repricing and debugging.

## Concurrency and latency budget

Assign provider-specific timeouts inside an overall search budget. If the SLA is 2 seconds, waiting 2 seconds independently for every provider is not a useful budget.

Reserve time for final merge and ranking.

## Failure modes

Typical failures include one slow supplier blocking the whole search, duplicate properties, stale rates, tax mismatches, retry amplification and incomplete ranking sets.

## Partial results

Returning useful early results can be better than waiting for every provider. The product and analytics layers must distinguish partial from final state.

## Observability

Track supplier success rate, latency percentiles, offers per supplier, property-mapping coverage, duplicate rate, partial responses, price mismatches and total search latency.

## Alternatives

For low volume with one or two predictable suppliers, simple synchronous orchestration can be enough. More suppliers and variable latency justify bounded fan-out, bulkheads and circuit breakers.

## Production checklist

Define supplier-specific timeouts, bounded concurrency, canonical search context, mapping, offer fingerprints, raw-response traceability, partial-result semantics, health-aware eligibility and provider-level metrics.