ARI Nedir? Availability, Rates & Inventory Rehberi

ARI, Availability, Rates & Inventory ifadesinin kısaltmasıdır.

Otelin belirli tarih ve ürün kombinasyonlarında satılabilir olup olmadığını, hangi fiyattan satıldığını ve ne kadar inventory bulunduğunu dağıtım sistemlerine aktarma modelini ifade eder.

Availability

Availability bir room/rate kombinasyonunun belirli stay date için satılabilir olup olmadığını gösterir.

Sadece room count değil, restriction'lar da availability'yi etkileyebilir.

Rates

Rate katmanı gecelik fiyat, currency ve rate-plan context'ini taşır. Fiyatın user-facing anlamı için taxes/fees, meal ve cancellation gibi metadata da önemlidir.

Inventory

Inventory belirli oda tipinin satılabilir kapasitesidir.

Inventory sıfıra düştüğünde rate var olsa bile offer sellable olmayabilir.

Restrictions

ARI sistemlerinde yalnızca fiyat ve adet yoktur.

Örnek kısıtlar:

• minimum stay,
• maximum stay,
• closed to arrival,
• closed to departure,
• stop sell.

Yanlış restriction technically valid görünen rate'i gerçekte unbookable hale getirebilir.

Push modeli

Google Hotels ARI yaklaşımı Pull modellerinden farklı olarak pricing/inventory state değişikliklerini partner'ın push etmesine dayanır. Bu nedenle partner değişikliği güvenilir biçimde tespit etmelidir.

Change detection

ARI entegrasyonunun kalbi şudur:

Hangi property / room / rate / date state'i değişti?

Incremental değişiklik üretmek ölçek avantajı sağlar; fakat kaybolan event stale state yaratabilir.

Snapshot ve reconciliation

Event-driven pipeline yanında periyodik reconciliation faydalıdır.

Örnek:

• incremental updates sürekli,
• nightly state validation,
• mismatch varsa replay/resync.

Bu model event kaybına karşı koruma sağlar.

Taxes, fees ve promotions

Google ARI dokümantasyonu taxes, fees ve promotions gibi alanların da daha geniş modelin parçası olabildiğini açıklar. ARI'yi yalnızca room count + price olarak düşünmek eksiktir.

Idempotency

Aynı state update tekrar geldiğinde sonuç bozulmamalıdır.

Property, room/rate, date ve version/timestamp boyutlarında deterministic davranış tasarlanmalıdır.

Monitoring

İyi metric seti:

• updates/min,
• accepted/rejected,
• processing latency,
• last update age,
• stale property count,
• retries,
• reconciliation mismatch,
• price accuracy.

ARI ne zaman mantıklı?

Inventory state size aitse, change event üretebiliyorsanız ve yüksek hacim varsa push tabanlı ARI doğal olabilir. Change-data pipeline zayıfsa query-driven bir model operasyonel olarak daha güvenli olabilir.

Özet

Başarılı ARI sistemi:

state ownership + change detection + reliable delivery + reconciliation + monitoring

gerektirir.

Production model: ARI state nasıl tutulmalı?

ARI entegrasyonunda en kritik hata, availability, rate ve inventory bilgisini tek bir "oda açık mı?" alanına indirmektir. Sağlıklı model room type, rate plan, date ve restriction state'ini ayrı tutar.

property
  -> room_type
      -> rate_plan
          -> date
              - rooms_to_sell
              - open/closed
              - min_stay
              - max_stay
              - closed_to_arrival
              - closed_to_departure
              - occupancy pricing
              - price

Bu yapı sayesinde "oda var ama bu rate plan kapalı", "rate açık ama inventory sıfır" veya "iki gecelik stay restriction'a takılıyor" gibi durumlar açıklanabilir.

Sync stratejisi nasıl kurulmalı?

Full refresh yerine mümkün olduğunda delta/event yaklaşımı daha verimlidir. Her outbound update için stable bir event identity üretmek replay ve idempotency'yi kolaylaştırır:

property + room + rate + date-range + change-type + version

Aynı event tekrar işlendiğinde state ikinci kez bozulmamalıdır.

En sık failure mode'lar

• room/rate mapping'in yanlış olması,
• timezone nedeniyle yanlış tarihe update yazılması,
• inventory update'in rate closure'dan sonra gelmesi,
• out-of-order event,
• failed retry sonrası local/remote state drift,
• full refresh'in yeni state'i eski data ile overwrite etmesi,
• restriction update'in price update'ten bağımsız kaybolması.

Bu nedenle yalnız request success rate değil state reconciliation gerekir.

İzlenmesi gereken KPI'lar

• accepted/rejected ARI update rate,
• update latency,
• provider error code dağılımı,
• local-vs-remote drift count,
• stale availability age,
• inventory mismatch,
• restriction mismatch,
• update retry count,
• booking sonrası inventory correction rate.

Production checklist

• Room ve rate ID mapping stable mı?
• Date/timezone contract açık mı?
• Delta update idempotent mi?
• Out-of-order event korunuyor mu?
• Remote state periyodik reconcile ediliyor mu?
• Error code'lar retryable/non-retryable ayrılıyor mu?
• Booking/cancellation inventory feedback loop'u çalışıyor mu?