TTL
Cache edilmiş verinin yeniden doğrulanmadan ne kadar süre kullanılabileceğini belirler. TTL booking intent, supplier latency ve change volatility'ye göre seçilmelidir.
Neden önemli?
Metasearch fan-out architecture upstream latency ve data volatility nedeniyle resilience gerektirir. Cache, timeout ve retry kararları yalnız backend performansını değil kullanıcıya gösterilen offer'ın doğruluğunu da etkiler. Bu kavramlar SLO, freshness ve failure isolation ile birlikte tasarlanmalıdır.
Pratikte nasıl görünür?
Bir supplier p95 latency'si yükseldiğinde timeout, circuit breaker ve fallback cache birlikte çalışabilir. Ama stale fallback kullanıldıysa response hâlâ başarılı görünürken price-quality riski büyüyebilir.
Uygulamada sorulması gerekenler
- End-to-end latency budget nedir?
- Cache age ve source timestamp tutuluyor mu?
- Hangi error class retry ediliyor?
- Bir provider failure diğer supplier'ları etkiliyor mu?
Yaygın hatalar
- Tüm error'ları retry etmek
- Cache hit ratio'yu freshness'ten bağımsız optimize etmek
- Tek provider failure'ın tüm fan-out'u bloklamasına izin vermek
Travel stack içinde nerede kullanılır?
TTL, çoğunlukla resilience katmanlarıyla ilişkilidir. İlgili sistemlerde source-of-truth, identity, freshness ve transaction ownership sınırlarını açık tanımlamak gerekir.
İlgili terimler
İlgili teknik içerikler
RoomCloud: Channel Manager ve Metasearch Connectivity Profili
RoomCloud'un real-time hotel distribution, PMS integration, reservation delivery ve metasearch connectivity rollerini teknik olarak inceleyin.
İncele →Travel Pricing için Cache Invalidation Patterns
Hotel ve flight fiyatlarında TTL, event invalidation, stale-while-revalidate ve live reprice sınırlarını production senaryolarıyla tasarlayın.
İncele →Metasearch'te Cache ve Price Freshness
Travel metasearch için cache ve price-freshness stratejisini gerçek search load, adaptive TTL, live recheck, stale-price risk, observability ve production trade-off'larıyla tasarlayın.
İncele →Booking Timeout / Outcome Unknown Troubleshooting
Travel booking timeout'larında duplicate retry yapmadan evidence, lookup, reconciliation ve recovery adımlarıyla UNKNOWN outcome teşhis edin.
İncele →Booking Timeout ve UNKNOWN Outcome Recovery
Travel booking timeout'larında FAILED yerine UNKNOWN state kullanarak lookup, reconciliation ve safe retry kararlarını tasarlayın.
İncele →Cendyn CRS: Central Reservations ve Distribution Profili
Cendyn'in central reservation ve hotel distribution rolünü reservation service ve live hotel-feed infrastructure bağlamında teknik olarak inceleyin.
İncele →