---
title: "Multi-Supplier Hotel Search Architecture"
description: "Birden fazla hotel supplier'ını tek arama akışında birleştiren fan-out, normalization, deduplication, timeout ve ranking mimarisini tasarlayın."
slug: "multi-supplier-hotel-search-architecture"
translationKey: "architecture-multi-supplier-hotel-search"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["hotel","architecture","supplier","fan-out","normalization"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

Birden fazla supplier ile hotel search yapmak, aynı request'i paralel göndermekten ibaret değildir. Asıl problem **farklı kimlik, rate, latency ve hata davranışlarını tek kullanıcı sözleşmesine dönüştürmektir**.

## Production senaryosu

Bir kullanıcı hotel/date/occupancy araması yapıyor. Sistem üç supplier ve bir direct hotel channel'ına gidiyor. Bazı provider'lar 300 ms'de, bazıları 2 saniyede dönüyor; aynı hotel farklı ID'lerle geliyor ve tax/fee semantiği değişiyor.

## Mimari akış

```mermaid
%% title: Multi-supplier hotel search akışı
%% description: Search request'in canonicalization, supplier fan-out, normalization, mapping, deduplication ve ranking adımlarından geçişi.
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]
```

## Temel domain nesneleri

- SearchContext
- CanonicalProperty
- SupplierPropertyRef
- RawOffer
- NormalizedOffer
- OfferFingerprint
- ProviderHealth
- SearchExecution

Supplier response'u doğrudan UI modeline çevrilmemelidir.

## Tasarım kararları

**Tüm supplier'ları her aramada çağırmak** coverage artırır ama latency ve maliyeti büyütür.

**Eligibility katmanı** market, hotel coverage, rate limit ve provider health'e göre fan-out setini küçültebilir.

**Normalization** provider-specific field'ları ortak modele taşır; fakat source-specific ID ve raw context kaybedilmemelidir.

## Concurrency ve latency budget

Her provider'a ayrı timeout verin. Search SLA 2 saniye ise dört supplier'ın her birine 2 saniye beklemek yanlış tasarımdır.

Örnek:

- overall budget: 1800 ms
- fast provider timeout: 700 ms
- slow provider timeout: 1200 ms
- final merge/render reserve: 200 ms

## Failure modes

- bir supplier tüm search'ü bloklar,
- duplicate property mapping,
- stale rate,
- tax/fee mismatch,
- response storm,
- provider retry amplification,
- ranking'e eksik offer girmesi.

## Partial results

İlk kullanılabilir sonuçları döndürmek, tüm provider'ları beklemekten daha iyi olabilir. Ancak UI ve analytics partial/final state'i ayırt etmelidir.

## Observability

- supplier success rate,
- p50/p95 latency,
- offers per supplier,
- mapped-property ratio,
- duplicate-offer rate,
- partial-response rate,
- price mismatch,
- search completion latency.

## Alternatifler

Düşük hacimde yalnız 1–2 supplier varsa synchronous orchestration yeterli olabilir. Yüksek supplier sayısı ve değişken latency'de fan-out orchestration + bulkhead/circuit breaker daha uygundur.

## Production checklist

- supplier-specific timeout
- bounded concurrency
- canonical SearchContext
- property mapping
- offer fingerprint
- raw response traceability
- partial-result contract
- health-aware eligibility
- provider-level metrics
- replay/debug capability