Pull vs Changed Pricing vs ARI: Google Hotels Fiyat Teslim Modelleri

Google Hotels fiyat entegrasyonunda Pull, Changed Pricing ve ARI aynı hedefe farklı yollarla ulaşır: Google'ın kullanıcılara güncel, rezervasyon yapılabilir rate göstermesi.

Doğru seçim “hangisi daha modern?” sorusundan değil, sizin change detection, latency ve scale kabiliyetinizden çıkar.

Karşılaştırma kapsamı

Bu sayfa bir kazanan seçmez. Karşılaştırma, aynı use case içinde hangi koşulda hangi modelin veya platform özelliğinin ne tür trade-off ürettiğini açıklar. Consumer UX, partner erişimi, commercial contract ve teknik entegrasyon aynı şey değildir; karar verirken bunları ayrı boyutlar olarak değerlendirmek gerekir.

Karşılaştırma

Pull

Google hangi hotel/itinerary fiyatını istediğini sorar; partner cevap verir.

Avantajı, fiyat değişikliklerini önceden bilmek zorunda olmamanızdır.

Zorlukları:

• request volume,
• latency,
• upstream dependency,
• timeout yönetimi.

Changed Pricing

Changed Pricing, Google'ın hangi kombinasyonları tekrar sorgulaması gerektiğini daha akıllı belirlemesine yardım eden change/hint yaklaşımı ekler.

Partner price change sinyali üretebiliyorsa gereksiz sorgu azalabilir.

Ancak change detection yanlışsa stale price riski ortaya çıkabilir.

ARI

ARI partner'ın availability/rate/inventory modelindeki değişiklikleri push etmesine dayanır.

Güçlü change-data pipeline'ı olan connectivity sistemleri için doğal olabilir.

Ancak ARI başarılı olmak için şunları gerektirir:

• doğru inventory state,
• incremental change tracking,
• restrictions,
• taxes/fees consistency,
• reliable delivery/retry.

Karar matrisi

Pull'a yakın durum

• source system only-on-demand pricing üretiyor,
• change events yok,
• query latency kabul edilebilir,
• upstream ölçeklenebilir.

Changed Pricing'e yakın durum

• hangi hotel/date tarafında değişiklik olduğunu biliyorsunuz,
• full ARI domain modeline geçmek istemiyorsunuz,
• query volume azaltmak istiyorsunuz.

ARI'ye yakın durum

• rate/inventory state sizin kontrolünüzde,
• incremental event üretebiliyorsunuz,
• yüksek hacimde push yaklaşımı tercih ediliyor,
• restrictions/promotions gibi domain alanları güçlü modellenmiş.

Hibrit düşünmek

Architecture decision tek bir endpoint seçmekten ibaret değildir.

Cache, live query, fallback ve monitoring katmanları pricing delivery modelinizin etrafında birlikte tasarlanmalıdır.

Ölçmeden karar vermeyin

Pilot sırasında ölçün:

• requests per property,
• p95 pricing latency,
• stale-price rate,
• update volume,
• API cost,
• price accuracy,
• recovery time after failure.

Bu veriler teorik mimari tercihinden daha güvenilir karar sağlar.

Sonuç

Pull, Changed Pricing ve ARI'nin amacı aynıdır; operational ownership farklıdır.

Kendi sisteminizde fiyatın ne zaman değiştiğini ne kadar iyi bildiğiniz, doğru delivery mode seçiminin merkezindedir.

Seçim kriteri: source-of-truth nerede?

Delivery mode seçiminde en faydalı soru “hangi protokol daha hızlı?” değil, rate/inventory state'in authoritative source'u nerede ve değişiklik sinyalini kim güvenilir biçimde üretebiliyor? sorusudur. Bu cevap cache, retry, replay ve observability tasarımını da belirler.