API Hız Sınırlama Stratejisi (Backoff)

Üstel geri çekilme (exponential backoff), başarısız bir istekten sonra (genellikle bir hız sınırına ulaşmak veya geçici bir sunucu hatası nedeniyle) bir sistemin her sonraki yeniden deneme girişiminden önce giderek daha uzun süre beklediği bir yeniden deneme stratejisidir — örneğin, 1. yeniden denemeden önce 1 saniye, 2. yeniden denemeden önce 2 saniye, 3. yeniden denemeden önce 4 saniye, 4. yeniden denemeden önce 8 saniye beklemek — bunun yerine hemen ve tekrar tekrar yeniden denemek, hatayı ilk başta oluşturan sorunu (aşırı yüklenmiş veya hız sınırlı bir API) daha da kötüleştirir. No-code geliştiriciler için neden önemli: otomasyon platformları, başarısız adımlar için yerel yeniden deneme mantıklarına giderek daha fazla üstel geri çekilme entegre ediyor (Zapier ve Make her ikisi de, geliştiriciye bir hata göstermeden önce belirli hata türlerini giderek artan gecikmelerle otomatik olarak yeniden dener), ancak bu kavramı anlamak, özel HTTP-istek tabanlı otomasyonlar tasarlarken, bir 429 "Too Many Requests" yanıtından sonra bir iş akışının ne kadar agresif yeniden deneme yapması gerektiğini yapılandırırken veya toplu işleme otomasyonunun neden sonunda başarılı olmak yerine bir başarısızlık patlamasından sonra "pes ediyor" gibi göründüğünü hata ayıklarken önemlidir. Geri çekilme olmadan, hız sınırlı bir API'ye karşı 10.000 kaydı işleyen naif bir otomasyon, 10.000 başarısız isteğin tümünü aynı anda ve hemen yeniden deneyebilir, bu da her yeniden denemenin de başarısız olmasını garanti eder — bir kesintiyi daha iyi hale getirmek yerine daha da kötüleştirebilecek kendinden kaynaklanan bir "yeniden deneme fırtınası". Nasıl çalışır: her başarısızlıkta, bekleme süresi genellikle iki katına çıkar (dolayısıyla "üstel"), çoğu zaman birçok paralel otomasyon çalıştırmasının tam olarak aynı anda yeniden denemesini ve aynı hız sınırı çarpışmasını birlikte yeniden tetiklemesini önlemek için bir miktar rastgelelik ("jitter") eklenir. Çoğu uygulama ayrıca maksimum bekleme süresini ve maksimum yeniden deneme sayısını sınırlar; bunun ardından sistem pes eder ve sonsuz yeniden deneme yerine hatayı bir insana gösterir. Uygulamalı örnek — hız sınırlı bir zenginleştirme API'sini çağıran bir n8n iş akışında geri çekilme uygulamak: "Hata Durumunda Yeniden Dene" etkinleştirilmiş, maksimum 5 yeniden deneme ve denemeler arasında artan bekleme süresi (1sn, 2sn, 4sn, 8sn, 16sn) ile yapılandırılmış bir HTTP İsteği düğümü; API bir `Retry-After: 30` başlığıyla 429 döndürürse, daha sofistike bir uygulama, API istemciye tam olarak ne kadar beklemesi gerektiğini açıkça söylediğinden, varsayılan geri çekilme programı yerine o başlığı okuyup sunucunun belirttiği süreyi bekler — başlık mevcut olduğunda en güvenilir yaklaşım budur. Bu desen — mevcut olduğunda sunucu tarafından belirtilen bekleme sürelerine saygı göstermek, mevcut olmadığında jitter'lı üstel geri çekilmeye geri dönmek — anlamlı hacimde harici bir API'ye tekrarlanan çağrılar yapan herhangi bir otomasyon için en iyi uygulama olarak kabul edilir.