Konuyu Açan
#1
Bir API çağrısında istemci zaman aşımına uğradı diye isteğin sunucuda da başarısız olduğunu varsaymak kolay; ama yanıt yolda kaybolmuş, model üretimi tamamlamış olabilir. Böyle bir durumda isteği körlemesine tekrarlamak hem yinelenen işlere hem de sağlayıcının ücretlendirme politikasına bağlı olarak gereksiz maliyete yol açabilir.
Ben entegrasyonda üç şeyi ayrı ele almayı faydalı buluyorum:
Siz hangi hatalarda otomatik tekrar deniyorsunuz? Kullandığınız API’de idempotency desteği yoksa yinelenen üretimleri nasıl önlüyorsunuz?
Ben entegrasyonda üç şeyi ayrı ele almayı faydalı buluyorum:
- Hata türünü ayırın: Bağlantı kurulmadan oluşan hata ile yanıt beklerken oluşan zaman aşımı aynı anlama gelmeyebilir. Geçici sunucu hataları için yeniden deneme düşünülebilir; doğrulama veya yetki hatalarında ise önce isteği düzeltmek gerekir.
- Yeniden denemeyi sınırlayın: Kısa bir üstel bekleme ve rastgele gecikme kullanıp deneme sayısına üst sınır koyun. Aksi hâlde yoğun bir servis sorunu, uygulamanızdan gelen eşzamanlı tekrarlarla büyüyebilir.
- İstek durumunu kaydedin: Sağlayıcı idempotency anahtarı destekliyorsa aynı mantıksal işlemde aynı anahtarı kullanın. Desteklemiyorsa kendi iş kimliğinizi ve işlem durumunu saklayın; özellikle akışlı yanıtlarda istemci bağlantısının kopması üretimin kesinlikle durduğu anlamına gelmeyebilir.
Siz hangi hatalarda otomatik tekrar deniyorsunuz? Kullandığınız API’de idempotency desteği yoksa yinelenen üretimleri nasıl önlüyorsunuz?