---
title: "Push vs Pull vs Hybrid: Travel Distribution Veri Akışı"
description: "Push, pull ve hybrid distribution modellerini freshness, latency, rate limit, cache, reconciliation ve operasyonel ownership açısından karşılaştırın."
slug: "push-vs-pull-vs-hybrid"
translationKey: "compare-push-vs-pull-vs-hybrid"
locale: "tr"
type: "comparison"
category: "architecture"
tags: ["push","pull","hybrid","distribution","cache","freshness"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
sources:
  - title: "Google Hotels — Pull / Changed Pricing / ARI"
    url: "https://developers.google.com/hotels/hotel-prices"
  - title: "Booking.com Connectivity APIs"
    url: "https://developers.booking.com/connectivity/docs"
---
Push, pull ve hybrid aynı distribution problemini farklı freshness ve ownership modeliyle çözer. Seçim yalnız trafik hacmine göre değil, **state volatility + latency budget + retry/reconciliation cost** birlikte değerlendirilerek yapılmalıdır.

## Karşılaştırma matrisi

| Boyut | Push | Pull | Hybrid |
|---|---|---|---|
| Trigger | Source değişiklik gönderir | Consumer/provider talep eder | Stable data push/cache, volatile state live pull/recheck |
| Freshness | Event delivery kadar iyi | Request anındaki source state | Katmana göre değişir |
| Read latency | Düşük olabilir | Upstream latency'ye bağlı | Cache hit düşük, miss/recheck daha yüksek |
| Write complexity | Retry/order/idempotency yüksek | Daha düşük outbound state management | İki model birlikte yönetilir |
| Rate-limit pressure | Change volume etkiler | Search/read volume etkiler | Her iki tarafta bounded |
| Drift riski | Lost/out-of-order event | Stale cache / timeout | Boundary yanlışsa iki tarafta |
| Reconciliation | Zorunlu | Faydalı | Zorunlu |

## Push ne zaman mantıklı?

ARI, inventory, restriction ve durable property/content değişiklikleri source-driven ise push verimlidir.

```text
Source state changes
  -> event/delta
  -> queue
  -> partner adapter
  -> delivery ledger
  -> acknowledgement
```

Ana risk delivery success ile business-state convergence'ı karıştırmaktır.

## Pull ne zaman mantıklı?

Price/availability çok volatile ve consumer request'i zaten hangi entity/date bağlamının gerektiğini belirliyorsa live pull daha doğru olabilir.

```text
User search
  -> provider request
  -> live response
  -> normalize
  -> render
```

Ana risk slow provider'ın tüm search latency budget'ını tüketmesidir.

## Hybrid neden yaygın?

Travel metasearch için doğal pattern:

```text
Property/content master -> feed/push/cache
Broad price coverage    -> cached/pushed state
User-selected context   -> live search/reprice
Final handoff           -> validation/reconciliation
```

Stable ve volatile datayı aynı sync modeliyle taşımak genellikle gereksiz maliyet veya stale state üretir.

## Idempotency ve ordering

Push modelinde event identity + source version gerekir.

Pull modelinde repeated request idempotent read gibi görünse de cache fill, analytics ve downstream side-effect'ler duplicate olabilir.

Hybrid modelde source-of-truth sınırı açık değilse eski pushed state yeni live observation'ı ezebilir.

## Failure modes

**Push**
- lost event,
- out-of-order delta,
- retry storm,
- silent drift.

**Pull**
- provider timeout,
- quota exhaustion,
- thundering herd,
- partial result.

**Hybrid**
- cache/source conflict,
- stale pushed state overriding live truth,
- inconsistent TTL/revalidation.

## Observability

Update delivery latency, stale-data age, polling volume, webhook/event failure rate, retry count, duplicate-event rate ve reconciliation backlog birlikte izlenmelidir.

## Karar kuralı

Data değişim frekansı düşük + consumer read yüksekse push/cache ekonomik olabilir.

Data çok volatile + request context yüksek cardinality ise live pull/reprice daha doğru olabilir.

Çoğu production travel system'da cevap **hybrid** olur, fakat hangi field'ın hangi source/time modeline ait olduğu explicit olmalıdır.

## Checklist

- [ ] Her field için source of truth belli mi?
- [ ] Freshness budget tanımlı mı?
- [ ] Event ordering/version var mı?
- [ ] Cache invalidation/revalidation tanımlı mı?
- [ ] Rate-limit pressure ölçülüyor mu?
- [ ] Partial result davranışı var mı?
- [ ] Periodic reconciliation var mı?