---
title: "Search Fan-Out ve Partial Results Architecture"
description: "Travel search'te paralel provider çağrılarını latency budget, bounded concurrency, early return ve final merge ile yönetin."
slug: "search-fanout-partial-results-architecture"
translationKey: "architecture-search-fanout-partial-results"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["fan-out","partial-results","latency","concurrency","search"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

Fan-out architecture'ın ana problemi paralellik değil, **yavaş veya bozuk provider'ların toplam search SLA'yı ele geçirmesini engellemektir**.

## Production senaryosu

Sekiz provider çağrılıyor. Beşi 500 ms altında, ikisi 1.5 saniyede, biri düzenli olarak timeout oluyor. Kullanıcı ilk sonuçları 1 saniye içinde görmek istiyor.

## Akış

```text
Request
 -> eligible providers
 -> bounded parallel calls
 -> stream/collect successes
 -> first useful threshold
 -> partial response
 -> late arrivals
 -> final merge
```

## Bounded concurrency

Provider sayısı 30 olduğunda 30 çağrıyı aynı anda başlatmak connection pool ve upstream limitleri bozabilir. Concurrency provider, region ve request priority bazında sınırlandırılmalıdır.

## Early return kriteri

“İlk provider döndü” yeterli değildir. Useful threshold tanımlayın:

- minimum X mapped hotels,
- minimum Y providers,
- ranking için gerekli offer diversity,
- max initial latency.

## Partial/final state

Response modelinde state açık olmalı:

```json
{
  "status": "partial",
  "completedProviders": 4,
  "pendingProviders": 2
}
```

UI final state gelmeden pricing sort'un değişebileceğini bilmelidir.

## Trade-off

Erken response latency'yi iyileştirir ama sonuç seti sonradan değişebilir. Tüm provider'ları beklemek determinism sağlar ama tail latency'yi büyütür.

## Failure modes

- late result ranking jump,
- duplicate merge,
- request cancellation propagation hatası,
- provider timeout sonrası orphan work,
- retry storm,
- partial analytics'in final ile karışması.

## Cache

Cache'i yalnız final response için düşünmeyin. Provider-level result cache ve stale-while-revalidate bazı supplier'larda tail latency'yi azaltabilir.

## Observability

- time-to-first-useful-result,
- time-to-final-result,
- completed provider count,
- partial-to-final delta,
- cancellation count,
- orphan task count,
- provider tail latency.

## Alternatif

Search sonucu küçük ve provider latency stabilse streaming/partial complexity gereksiz olabilir. Tail latency yüksekse önemli fayda sağlar.

## Production checklist

- overall latency budget
- provider timeout
- bounded concurrency
- cancellation propagation
- partial state contract
- dedup on late merge
- deterministic ranking tie-break
- separate partial/final analytics