Polling
Bir state değişikliğini event beklemek yerine belirli aralıklarla API'den sorgulama yöntemidir. Polling interval, rate limit ve eventual consistency birlikte tasarlanmalıdır.
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?
Polling, çoğunlukla resilience, transaction 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
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 →Booking Timeout ve Duplicate Booking Playbook
Booking create timeout sonrası unknown state ve duplicate reservation riskini idempotency, lookup ve reconciliation adımlarıyla yönetin.
İ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 →Cancellation Succeeded but Local State Stale
Provider cancellation başarılı olduğu halde local booking state güncellenmediğinde webhook, persistence, ordering ve reconciliation katmanlarını teşhis edin.
İncele →Canonical Offer, Order ve Booking State Model
Travel sistemlerinde Offer, Order ve Booking kavramlarını ayıran canonical state modelini ve booking state machine tasarımını kurun.
İncele →NDC Offer/Order Lifecycle: Search'ten Servicing'e
NDC Offer/Order lifecycle'ını search, offer, revalidation, order create, payment, ticketing, servicing ve reconciliation state'leriyle modelleyin.
İncele →