Hani, Geçen ay, İstanbul’da bir akşamüstü — tam da servislerin en sevmediği saatlerde — bir backend ekibiyle konuşurken aynı dert yeniden önüme çıktı: “Bir istek niye üç kere patlayınca sistem dağılıyor?” Cevap aslında çok tanıdık. Çoğu ekip retry işini ilk bakışta küçücük bir for döngüsüyle çözüyor. Hani şu masum görünen, prod’a çıkınca ise küçük bir domino taşı gibi bütün zinciri deviren yapı…
İşin aslı şu: retry, sadece “bir daha dene” demek değil. Zamanlama var, geri çekilme var, hata türü ayrımı var, gözlemlenebilirlik var. Ben bunu 2023 sonbaharında kendi küçük SaaS projemde çok net gördüm; üçüncü parti ödeme servisi kısa aralıklarla çökünce basit retry mantığım kendi trafiğimi şişirmeye başlamıştı. O gün anladım: sağlam retry, bir kod parçası değil, mini bir sistemdir.
Retry mantığı “yeniden dene” kadar basit görünür ama prod ortamında asıl mesele hız değil; kontrollü bekleme, doğru hata seçimi ve sistemi yormadan ayakta kalmak.
p-retry ve daha yeni, sade kurulumlu retry-pro. Hangisinin iyi olduğu biraz da sizin kullanım senaryonuza bağlı.
Neden Basit Retry Çoğu Zaman Yetmiyor?
Lafı gevelemeden söyleyeyim. O meşhur try/catch içinde bekleyip — kendi adıma konuşayım — tekrar deneme modeli kağıt üstünde fena durmaz — hatta ilk testte “tamam ya, iş görüyor” dersiniz. Ama trafik artınca olay değişiyor. Bu ne anlama geliyor? Bir servis yavaşladığında siz de aynı anda tekrar tekrar vuruyorsunuz ve sistemin omzuna gereksiz yük bindiriyorsunuz; üstelik bu yük birikince artık sorunu çözmek değil, tam tersine büyütmek oluyor işiniz.
Tuhaf ama, Benzer sahneyi geçen yıl Berlin’de çalışan bir arkadaşım anlattı. Mikroservis mimarisinde küçük bir timeout sorunu yüzünden loglar gürültüye dönmüş (ki bu çoğu kişinin gözünden kaçıyor). Çünkü her hata aynı şekilde retry edilmiş — yani 400 hatası da denemişler, 500 hatası da. Tehlikeli bir alışkanlık bu. Kötü istekleri yeniden göndermek bazen iyileştirme değil, düpedüz zarar veriyor.
Hani, Gel gelelim asıl meseleye (bizzat test ettim). Exponential backoff yoksa sunucuya sanki sabah trafiğinde korna çalar gibi yükleniyorsunuz. Jitter yoksa yüzlerce worker aynı anda uyanıp aynı anda tekrar ediyor — bu da retry storm denen tatsız tabloyu doğuruyor. Siz hiç denediniz mi? Bir noktada sorun çözmek yerine büyütüyorsunuz.
Bir dakika — bununla bitmedi.
Klasik modelde eksik kalan parçalar
- Exponential backoff yoksa: her deneme eşit aralıkla gelir ve servis kendine gelemez. (bu kritik)
- Jitter yoksa: tüm istemciler aynı ritimde saldırır.
- Error filtresi yoksa: kalıcı hatalar bile boşuna yeniden denenir.
- Tek tek timeout yoksa: uzun süren istekler kuyruğu kilitler.
- Hook/log yoksa: ne olduğunu sonradan anlamak zorlaşır. — bunu es geçmeyin
retry-pro Ne Vaat Ediyor?
retry-pro tam burada devreye giriyor ve “retry işini ben paketledim” diyor. Açık konuşayım — fikir kötü değil. Bilhassa de de ekip içinde herkesin farklı şekilde yazdığı tekrar deneme mantığını tek tip hale getirmek isteyenler için bayağı pratik görünüyor. Kurulum kısa, API sade, üstüne bir de yaşam döngüsü hook’ları var.
Editör masasındayken bu tarz kütüphaneleri görünce hemen test etme isteğim oluyor. Geçen hafta Kadıköy’de kahvemi içerken örnek kodu inceleyince aklıma ilk gelen şey şuydu: bu yapı yeni başlayan ekiplere ciddi zaman kazandırabilir, ama biraz fazla güven veren bir tarafı da var — kolay kurulum bazen insanı detayları atlamaya itebiliyor, hani “zaten kütüphane halleder” deyip geçme durumu işte.
Kısa bir not düşeyim buraya.
retry-pro‘nun öne çıkan tarafı şu üçlüde toparlanıyor gibi duruyor: kontrol, görünürlük ve az kodla iş bitirme hissi. Ama evet, her güzel hikâyede olduğu gibi burada da küçük bir hayal kırıklığı payı var; topluluk dünyai ve oturmuşluk açısından p-retry‘nin gerisinde kalması normal karşılanabilir.
| Kriter | retry-pro | p-retry |
|---|---|---|
| Kullanım kolaylığı | Bayağı sade | Sade ama biraz daha klasik |
| Error seçimi | Daha yönlendirilmiş hissettiriyor | Daha esnek ve oturmuş |
| Lifecycle hook’ları | Dikkat çekici derecede rahat | Zaten kuvvetli taraflarından biri |
| Ekip adaptasyonu | Küçük ekipte hızlı benimsenir | Büyük ekipte daha tanıdık gelebilir |
| Tolere edilen risk seviyesi | Kullanıma göre iyi | Daha kanıtlı |
Nerede iyi çalışır?
Küçük bir startup düşünün. Üç kişi backend yazıyor, biri frontend’e kaçıyor, biri de deployment’a bakıyor. Böyle yerlerde kısa kurulum gerçekten önemli oluyor — bir komutla ilerlemek çoğu zaman yeterli geliyor çünkü ekip zaten operasyonel yük altında eziliyor, ayrıca saatler harcayıp kütüphane araştıracak vakitleri de pek olmuyor (ben de ilk duyduğumda şaşırmıştım)
Durun, bir saniye.
E tabi enterprise tarafta resim değişiyor. Orada standartlaşmış observability araçları, merkezi logging politikaları ve güvenlik incelemeleri devreye giriyor. İşte orada kütüphanenin sadece kolay olması yetmiyor; bakım ömrü, sürüm disiplini ve hata davranışı da önem kazanıyor.
Peki p-retry Neden Hâlâ Güçlü?
Bi saniye — Yıllardır adı geçen o sağlam araçlardan biri gibi duruyor p-retry. Fazla süslü değil. Ama oturmuş hissi veriyor — hani bazı alet kutularında yıllardır duran tornavida vardır ya, gösterişli değil. Gerektiğinde işi hep halleder. Tam öyle. Bu konuyla ilgili Apple’ın Yeni M5 MacBook Air’i İndirime Girdi: Fiyatlar Düştü yazımıza da göz atmanızı tavsiye ederim.
Bende bıraktığı izlenim şu oldu: eğer takımınızın önceliği kanıtlanmış davranışlar ve geniş kullanım geçmişiyse, p-retry kafa rahatlatan seçeneklerden biri. Hele bir de production’da “acaba bu kenar durumunu düşündük mü?” sorusunun cevabını çok kez vermiş projelerde böyle kütüphaneler altın değerinde oluyor.
Kimin için daha uygun?
Bence orta-büyük ölçekli ürünlerde veya birkaç takımla ortak kullanılan altyapılarda p-retry‘nin ağırlığı hissediliyor. Çünkü insanlar bilinmeyeni sevmez — özellikle gecenin ikisinde alarm çaldığında kimse sürpriz istemez! Daha önce adını duymuş olmak bile bazen teknik borcu azaltıyor.
Doğrusu, Buna karşılık retry-pro gibi yeni çözümler, belirli ihtiyaçlara odaklanıp fazlalıkları atınca oldukça cazip hale geliyor. Mesela sadece async fonksiyonlarda temiz retry istiyorsanız ve logging/hook düzenini kendi uygulama katmanınızda tutuyorsanız gayet mantıklı olabilir. Ancak yine de “ham” tarafını unutmamak lazım; yeni araçların parlak yüzüne kapılıp destek ekosistemini göz ardı etmek pek akıllıca olmaz.
Sahada Nasıl Kullanılır? Küçük Örneklerle Bakalım
Basit senaryo
Şahsen, Aşağıdaki yapı kafayı karıştırmadan ana fikri gösteriyor:
import { retryAsync } from "retry-pro";
const data = await retryAsync(fetchData, {
retries: 3,
initialDelay: 200,
maxDelay: 2000,
jitter: true
});Bunu görünce insanın içinden “hepsi bu mu?” demesi normal. Evet, büyük ölçüde bu kadar sade olabiliyor. Ama kritik nokta şu: asıl güç satır sayısında değil, arkadaki davranış modelinde gizli. Bu konuyla ilgili LLM Mühendisliğinde 10 Temel Kavram: Kısa Rehber yazımıza da göz atmanızı tavsiye ederim.
Daha gerçekçi kullanım
const user = await retryAsync(async () => {
const res = await fetch("/api/user");
if (!res.ok) {
const err = new Error("Request failed");
err.retryable = res.status >= 500;
throw err;
}
return res.json();
}, {
retries: 5,
initialDelay: 200,
maxDelay: 5000,
jitter: true,
retryIf: (err) => err.retryable,
});Bu örnekte hoşuma giden şey şu oldu: yalnızca gerçekten geçici olabilecek hataları hedefliyorsunuz. Kullanıcı yanlış veri girdiyse onu boş yere beş kez yeniden denemiyorsunuz — dürüstçe fail ediyorsunuz. Bu hem performans hem de debug açısından çok daha temiz bir yaklaşım, açıkçası bu ayrımı yapmayan sistemler beni hep biraz rahatsız etti.
Bir dakika, şunu da ekleyeyim: per-attempt timeout varsa işler daha da toparlanıyor, çünkü her deneme kendi sınırına sahip oluyor ve birinin uzaması diğerlerini bloke etmiyor.
Mimaride Düşünmek Gerekir mi? Evet Gerekir!
Retry meselesini genelde fonksiyon seviyesinde konuşuyoruz. Ama etkisi mimariye yayılıyor — bunu çok gördüm. Bir üçüncü parti API çağrısı düşünün; Stripe olabilir, Firebase olabilir ya da kendi iç servisinizden biri. Eğer sınırsız sabırla her şeyi yeniden denersek sorun çözülmüyor, sadece erteleniyor. Daha fazla bilgi için pro ile ilgili önceki yazımız yazımıza bakabilirsiniz.
Kurumsal projede çalışırken en sık gördüğüm problem buydu:
- Timeout ayrı yönetilmiyordu.
- Retryable olmayan hatalar ayıklanmıyordu.
- Log’lar yeterince anlamlı değildi.
- Aynı anda bin tane job kalkıp sistemi dürtüyordu.
Şimdi gelelim pratik ayrımı netleştirmeye:
- Küçük startup: Az kodla hızlı entegrasyon öncelik olur.
- SaaS ürünü: Hook’lar ve görünürlük öne çıkar. — ciddi fark yaratıyor
- Büyük kurum: Oturmuş davranış + bakım kolaylığı + standartlar önemli olur.
Ha bu arada — array_map ile ilgili yazımızda temiz kodun bedelinden söz etmiştik; burada da benzer bir durum var aslında. Az kod yazmak bazen iyi hissettirir ama üretimde gerçek maliyet başka yerde çıkar.
Tartının Kefesi Hangisine Yakın?
Açık konuşayım. Tek doğru cevap yok. TSMC’ye Giden Yol: Apple’ı Sarsan Çip Gölgesi yazımızda da bu konuya değinmiştik.
Eğer amacınız minimal kurulumla modern async retry almaksa retry-pro sizi mutlu edebilir. Ama yıllardır kullanılan araçlara yaslanmak istiyorsanız p-retry hâlâ güçlü bir aday — bunu söylemekten çekinmiyorum.
Ben olsam şöyle düşünürdüm:
| Senaryo | Daha Mantıklı Seçim |
|---|---|
| Yeni proje / hızlı MVP | retry-pro |
| Olgun üretim sistemi | p-retry |
| Hook ağırlıklı özel akış | retry-pro |
| Topluluk desteği öncelikli | p-retry |
Tabii bu tablo kutsal taş tablet değil. Projenizin ölçeği büyüdükçe karar değişebilir — mesela dün retry-pro size yeterken yarın audit gereksinimi nedeniyle başka beklentiler doğabilir. Hayat böyle.
Bu konuda %100 emin değilim. Sanırım en sağlıklı yaklaşım şu: önce gerçek hata profilinizi ölçün, sonra hangi aracın onu daha az acıyla yönettiğine bakın. Neyse uzatmayalım — retry’nin özü araçtan çok davranıştır.
Sıkça Sorulan Sorular
`retry-pro` ile `p-retry` arasındaki temel fark ne?
`retry-pro`, sade kurulum ve built-in hook yapısıyla öne çıkıyor gibi duruyor.
`p-retry` ise daha uzun süredir kullanılan, oturmuş ve güven veren bir seçenek.
Eğer hızla başlamak istiyorsanız ilki cazip gelebilir; stabilite önceliğinizse ikincisi hâlâ çok güçlüdür.
Peki exponential backoff neden önemli?
Cevap basit:
Aynı anda tekrar eden istekleri dağıtmak için gerekiyor.
Böylece servis üzerindeki baskıyı azaltıyorsunuz. Kendinizi gereksiz trafik dalgasından koruyorsunuz.
Error’ların hepsi neden yeniden denenmemeli?
Çünkü bazı hatalar geçici değildir.
Misal yanlış parametre göndermişsinizdir ya da yetki eksiktir.
Bunları tekrar etmek problemi çözmez; sadece log’u kirletir.
Küçük ekipler için hangisi daha rahat?
Şunu söyleyeyim, Küçük ekiplerde genelde hızlı entegrasyon kazandırır.
`retry-pro` burada iyi hissettirebilir (kendi tecrübem). Daha az kurcalama ister.
Ama takımınız zaten `p-retry` biliyorsa o yoldan gitmek de gayet makuldür.
Kaynaklar ve İleri Okuma
Tuhaf ama, P-Retry GitHub Sayfası
GitHub Ana Sayfası — Proje Araması İçin Başlangıç Noktasıdır (evet, doğru duydunuz)
Node.js Fetch Dokümantasyonu — Resmi Rehber
MDN Promise Referansı — Asenkron Davranışı Anlamak İçin İyi Bir Başlangıçtır;
Array_map Her Derde Deva Değil Temiz Kodun Bedeli:
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
