---
title: "Metasearch'te Supplier Latency ve Timeout Budget"
description: "Hotel ve flight metasearch search pipeline'ı için timeout budget, paralel supplier call, partial result, circuit breaker ve latency SLO yaklaşımını öğrenin."
slug: "supplier-latency-timeout-budgets"
translationKey: "learn-supplier-latency-timeout-budgets"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["latency","timeout","supplier","resilience","search","metasearch"]
publishedAt: "2026-09-20"
updatedAt: "2026-09-20"
reviewedAt: "2026-09-20"
sources:
  - title: "Google Hotels Pricing overview"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/updating-prices"
  - title: "Skyscanner API Developer Documentation"
    url: "https://developers.skyscanner.net/"
---
Metasearch latency'si fan-out search içindeki en yavaş katmanlardan etkilenir: upstream supplier, normalization ve ranking. Resilient tasarım her aşamaya zaman bütçesi verir ve tek yavaş provider'ın tüm sayfayı bloke etmesi yerine anlamlı partial result döndürür.

## End-to-end search budget ile başlayın

İlk faydalı sonucun ve complete search'ün maksimum süresini tanımlayın. Ardından bu bütçeyi gateway, supplier call, normalization, deduplication, ranking ve rendering arasında bölün.

Kullanıcıya iki saniyede sonuç göstermeyi hedefliyorsanız her supplier'a ayrı ayrı iki saniye timeout veremezsiniz.

## Parallel fan-out tek başına yeterli değildir

Hotel ve flight metasearch birden fazla kaynağı eşzamanlı çağırır. Paralel çağrı total latency'yi azaltır ama her search her provider'a giderse load ve failure amplification yaratabilir.

Provider eligibility, market relevance, cache coverage ve geçmiş quality verisine göre hangi supplier'ın sorguya katılacağını seçin.

## Provider bazlı timeout kullanın

Her provider aynı timeout'u hak etmek zorunda değildir. Stable şekilde 600 ms'de dönen yüksek-conversion supplier ile üç saniye süren düşük-yield provider farklı budget alabilir.

Average yerine provider/endpoint bazında p50, p95 ve p99 izlemek daha anlamlıdır.

## Partial result bir ürün kararıdır

Tüm provider'ları beklemek experience'i yavaşlatabilir. İlk faydalı offer set'ini render edip kısa süre içinde geç gelen supplier'ları eklemek çoğu zaman daha iyi perceived speed üretir; fakat UI sürekli re-sort olup zıplamamalıdır.

Pratik pattern:

1. cached veya hızlı provider sonuçlarını göster,
2. kısa secondary window içinde late result merge et,
3. hard deadline sonrası response kabul etme,
4. deadline kaçıran provider'ı metric olarak kaydet.

## Timeout evidence üretmeli

Timeout yalnız exception değildir. Provider, endpoint, query class, elapsed time, retry count ve fallback gösterilip gösterilmediğini kaydedin.

Böylece “offer yok” ile “supplier zamanında cevap vermedi” birbirinden ayrılır.

## Retry latency'yi daha kötü yapabilir

Interactive request içinde yavaş upstream'i tekrar çağırmak tüm budget'ı tüketebilir. Retry yalnız açıkça transient error için bounded olmalı; recovery mümkünse critical path dışında yapılmalıdır.

Exponential backoff asynchronous refresh ve feed processing için interactive iki saniyelik search'e göre daha uygundur.

## Circuit breaker sistemi korur

Supplier sürekli timeout veya error veriyorsa full traffic göndermeye devam etmek thread, connection ve outbound capacity tüketir. Circuit breaker veya health-based routing provider düzelene kadar çağrı hacmini azaltabilir.

Upstream incident sırasında bu davranış tüm platformun etkilenmesini önler.

## Meta Search yorumu

Latency control aslında workload orchestration'dır. Search için açık end-to-end budget tanımlayın, provider deadline'larını ayırın, partial result'ı bilinçli kullanın, timeout evidence tutun ve tek bozuk entegrasyonun bütün search deneyimini yavaşlatmasını engelleyin.

## End-to-end budget'i provider'lara nasıl dağıtmalı?

Kullanıcıya 2 saniyede anlamlı result göstermek istiyorsanız her supplier'a 2 saniye timeout veremezsiniz.

Örnek budget:

```text
request parsing         50 ms
cache/entity lookup    100 ms
supplier fan-out      1200 ms
normalization          150 ms
ranking                100 ms
render/network reserve 400 ms
-----------------------------
total                 2000 ms
```

Provider deadline bu shared budget içinde hesaplanmalıdır.

## Hedging ve partial result ne zaman kullanılmalı?

Fast provider'lar ilk result set'i oluşturabilir; late provider kısa secondary window içinde merge edilebilir. Ancak late offer geldiğinde UI sürekli reorder olursa perceived quality düşebilir.

Hedged request yalnız belirli provider'ın latency tail'i yüksekse ve duplicate request cost kabul edilebiliyorsa düşünülmelidir.

## Failure isolation

- circuit breaker,
- bulkhead/concurrency limit,
- per-provider queue,
- timeout budget,
- fallback cache,
- health-based routing

bir supplier incident'ının tüm search cluster'ını tüketmesini engeller.

## KPI'lar

- p50/p95/p99 by provider,
- deadline miss rate,
- partial-result rate,
- late-response discard,
- fallback-cache rate,
- circuit-open duration,
- conversion by latency bucket.

Latency optimizasyonu yalnız speed değil; **coverage kaybetmeden tail latency'yi kontrol etme** problemidir.


## Production kontrol listesi

- End-to-end latency SLO ve first-useful-result hedefini ayrı tanımlayın.
- Provider/endpoint bazında timeout budget kullanın.
- Fan-out concurrency için bulkhead sınırı koyun.
- Partial ve final result state'lerini analytics'te ayırın.
- Timeout, retry ve fallback sonucunu correlation ID ile loglayın.
- Circuit breaker recovery için half-open probe tanımlayın.
- Provider latency percentile ve deadline-miss alert'lerini izleyin.
- Değişiklik sonrası conversion/coverage kaybını latency kazanımıyla birlikte değerlendirin.