Idempotency Key
Aynı logical mutation'ın retry edildiğinde ikinci kez uygulanmasını önlemek için kullanılan stable request anahtarıdır. Booking, payment ve order creation gibi side-effect işlemlerde kritiktir.
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?
Idempotency Key, çoğunlukla resilience, transaction, agentic 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
Agentic Travel Transaction Safety
Agent loop, retry ve tool invocation kaynaklı duplicate booking/payment riskini idempotency, transaction guards ve UNKNOWN-aware recovery ile yönetin.
İncele →Webhook Replay ve Idempotency Troubleshooting
Tekrarlanan, geciken veya sırası bozulan webhook event'lerini idempotency key, dedup store ve replay kurallarıyla güvenli biçimde yönetin.
İncele →Agentic Travel Reference Architecture
AI agent → search → offer → reprice → confirmation → payment → booking → servicing akışını travel-specific authorization, idempotency ve audit sınırlarıyla tasarlayın.
İncele →Duplicate Booking After Retry Troubleshooting
Timeout veya retry sonrası oluşan duplicate travel booking'leri identify edin, kanıt toplayın, doğru rezervasyonu koruyup güvenli compensation uygulayın.
İncele →Idempotency ve Duplicate Booking Prevention
Travel booking create, payment, cancellation ve refund operasyonlarında idempotency sınırlarını ve duplicate booking önleme desenlerini tasarlayın.
İncele →Payment + Booking Distributed Transaction
Travel booking'de payment ve supplier booking adımlarını distributed transaction olarak modelleyin; authorize, capture, compensation, UNKNOWN outcome ve reconciliation desenlerini uygulayın.
İncele →