Exponential Backoff: Her Hata İçin Gerekli Değil, Doğru Yerde Kullan

Anket

Exponential backoff'u ne sıklıkla kullanıyorsunuz?

0 oy

Exponential backoff bugün bir tür cargo cult haline geldi. Bir API çağrısı başarısız olunca, herkes hemen 2^n saniye bekleyip yeniden deniyor. Ama doğru mu bu?

Exponential backoff'un mantığı basit: ağ geçici olarak aşırı yüklenmiş olabilir, o yüzden bir süre bekle; yine başarısız olursa daha uzun bekle. İlk deneme başarısızsa 1 saniye, sonra 2, sonra 4, sonra 8... Sistem rahatlarken sen de sabredin.

Bu strateji gerçekten işe yarar, ama sadece belirli koşullarda. Eğer bir dış API'ya istek gönderiyorsan ve o API'nın rate limit'i varsa, exponential backoff akıllıca bir seçim. AWS, Google Cloud, Stripe gibi büyük servislerin hepsi bunu tercih ediyor. Geçici ağ hataları veya sunucu overload durumlarında da işe yarar.

Ama burada başlayan sorun şu: her başarısız istek için exponential backoff uygulamak gereksiz. Örneğin, bir veritabanı sorgusunda bağlantı timeout'ı alırsan, hemen 8 saniye beklemek mantıklı değil. Sorun genelde kalıcı, yanlış query, kimlik doğrulama hatası, veri yok. Beklemek sorunu çözmez.

Reklam · TEST
AdSense Test ReklamıYazı arası (gönderi içi) · Yazı arası

Bir diğer tuzak: jitter eklemeyi unutmak. Eğer binlerce istemci aynı anda exponential backoff uygulamaya başlarsa, hepsi aynı zamanda yeniden deneyecek ve sistemi tamamen çökerteceksiniz. Jitter (rastgele bir gecikme ekleme) bu sorunu çözer; ama çoğu implementasyon bunu atlar.

Praktik yaklaşım şu: backoff'u hata türüne göre ayarla. 429 (Too Many Requests) veya 503 (Service Unavailable) aldıysan, exponential backoff haklı. 400 (Bad Request) veya 401 (Unauthorized) aldıysan, beklemek aptalca. Hemen fail et, log'la ve geç.

Bir başka nokta: maksimum deneme sayısını ve maksimum bekleme süresini belirle. Sonsuz beklemek yoktur. Genelde 3-5 deneme ve maksimum 30-60 saniye yeterli. Daha uzun beklemek kullanıcı deneyimini mahveder.

Sonuç: exponential backoff iyi bir araç, ama ilaç değil. Dış API'lar, geçici ağ sorunları ve rate limiting için kullan. Kalıcı hatalar için harcamayın. Jitter ekle, maksimum sınırı belirle, hata kodlarına göre kararını ver. Hiçbir şey yapı taşı değildir; bağlama bağlı.

Reklam · TEST
AdSense Test ReklamıGönderi altı · Görüntülü
konu hakkında tepkinizi verebilirsiniz