1. GİRİŞ

Yeniden deneme (retry) desenleri, dağıtık sistemler ve mikroservis mimarilerinde hataya dayanıklılığı artırmak için temel bir tekniktir. Ağ hataları, geçici servis kesintileri veya zaman aşımı gibi durumlarda kontrollü yeniden denemeler kısa süreli aksaklıkların sistem davranışını bozmasını engeller. Ancak retry mekanizmaları bilinçsiz uygulanırsa cascading failures, thundering herd veya duplicate side‑effect gibi sorunlara yol açabilir. Bu rehberde retry stratejilerinin neden konuşulduğunu, hangi senaryolarda gerektiğini, teknik varyasyonlarını ve pratik uygulama önerilerini mühendis bakış açısıyla ele alacağız.

Bu konu neden konuşuluyor?

• Dağıtık çağrılar daha sık kullanılınca transient hatalar daha görünür oldu; retry, dayanıklılık sağlamak için ilk savunma hattıdır.
• Mobil, edge ve global uygulamalarda ağ dalgalanmaları yaygın; kullanıcı deneyimini korumak için akıllı retry uygulamaları gerekiyor.
• Bulut servisleri ve üçüncü taraf API'ler rate limiting ve throttling uygulayabiliyor; doğru retry politikaları sistem kararlılığı için kritik.

Kimler için önemli?

• Backend geliştiriciler ve entegrasyon mühendisleri
• Platform mühendisleri, SRE ve DevOps ekipleri
• Product ekipleri — SLA ve kullanıcı deneyimi sorumluları

Hangi problemleri çözüyor?

• Geçici hatalar nedeniyle başarısız olan işlemleri otomatik tamamlayarak kullanıcı aksiyonlarını güvence altına almak
• Geçici servis bozulmalarının neden olduğu manuel müdahaleyi azaltmak
• Kısa süreli ağ veya altyapı sapmalarının etkisini sınırlandırmak

2. KAVRAMSAL TEMELLER

2.1 Retry nedir?

Retry, bir isteğin başarısız olması durumunda belirlenmiş kurallara göre tekrar denenmesidir. Temel amaç transient (geçici) hataların üstesinden gelmek ve işlemi başarılı şekilde tamamlamaktır. Ancak retry sadece tekrar çağrı yapmak değildir; zamanlama, sınır, idempotency ve geri kasa (fallback) gibi unsurların koordinasyonudur.

2.2 Temel terminoloji

Retry Count

İstenen maksimum deneme sayısı.

Delay

Denemeler arasındaki bekleme süresi (fixed, linear, exponential).

Backoff

Arttırılan gecikme stratejisi; örn. exponential backoff.

Jitter

Backoff sürelerine rastgelelik ekleme tekniği; thundering herd'i önler.

Retry Budget

Sistem genelinde veya istek başına izin verilen toplam retry kaynak limiti.

Idempotency

Aynı işlemin birden çok kez çalıştırılmasının yan etki üretmemesi garantisi; retry için kritik.

Dead Letter Queue (DLQ)

Bir işlem belirlenen retry sınırlarından sonra hâlâ başarısız olursa kaydedildiği özel kuyruk veya depo.

2.3 Neden sadece "sonsuz retry" iyi değildir?

Sonsuz veya kontrolsüz retry, bağımlı servisler üzerinde artan yük yaratır, kaynak tüketimini artırır ve sistem genelinde kemikleşmiş gecikmelere yol açar. Ayrıca duplicate side‑effect riski vardır. Bu yüzden retry stratejileri sınır, backoff ve idempotency ile birlikte düşünülmelidir.

3. NASIL ÇALIŞIR? — TEKNİK STRATEJİLER

3.1 Basit yaklaşımlar

Immediate retry

Başarısızlık olduğunda hemen tekrar denemek. Küçük ve düşük gecikmeli operasyonlar için işe yarar ancak bir bağımlı servis yük altındaysa sorunu ağırlaştırabilir.

Fixed delay

Denemeler arasında sabit bir bekleme süresi koymak. Uygulaması kolaydır fakat yoğun sistemlerde koordinasyon sağlamaz.

Linear backoff

Gecikme her denemede sabit bir miktar artar (ör. +200ms). Fixed delay'den biraz daha naziktir, fakat yüksek trafik senaryolarında sınırlı etkiye sahiptir.

3.2 Exponential backoff

Gecikme katlanarak büyür (ör. 100ms, 200ms, 400ms, 800ms). Exponential backoff, kısa sürede tekrar denemeye göre daha az baskı uygular ve geçici hataların düzelmesi için zaman tanır. Google'ın ve AWS gibi birçok servis sağlayıcının önerdiği temel yaklaşımdır.

3.3 Exponential backoff with jitter

Jitter, aynı anda çok sayıda istemcinin aynı backoff sürelerini takip edip aynı anda yeniden denemesini engellemek için backoff'a rastgelelik eklemek demektir. İki yaygın jitter stratejisi vardır:

• Full jitter: Rastgele değeri 0 ile base_backoff arasında seçme.
• Decorrelated jitter: Son backoff ve max_backoff kullanarak yeni bir rastgele süre üretme; koordinasyon riskini daha fazla azaltır.

3.4 Retry budget ve circuit coordination

Retry budget, sistem genelinde veya tenant düzeyinde izin verilen retry tüketimini sınırlandıran bir kaynaktır. Bir sistem her başarılı istek için belirli bir retry kredisi kazanabilir ve bu kredi harcanarak retry yapılır. Bu yaklaşım, yoğun baskı altındaki bağımlılıklara yönelik toplu retry patlamalarını engeller. Retry, circuit breaker gibi diğer resiliency desenleriyle koordineli çalışmalıdır: bağımlı servis hata veriyorsa circuit açık olmalı ve retry'ler sınırlandırılmalıdır.

3.5 Server‑side vs client‑side retry

Retry mantığı hem istemci tarafında hem de sunucu tarafında uygulanabilir. Client‑side retry, istemcinin başarısızlığı algılayıp yeniden denemesidir. Server‑side retry ise proxy, gateway veya msg broker üzerinde yapılır (örn. API Gateway, Mesh). Her iki tarafın da birlikte çalışması dikkat ister: çift taraflı retry kontrolsüz retry patlamalarına neden olabilir; koordinasyon için idempotency ve retry budget kullanın.

3.6 Retries for asynchronous processing

Mesaj tabanlı sistemlerde (RabbitMQ, SQS, Kafka) retry genellikle kuyruğa yeniden koyma, gecikmeli kuyruk (delay queue) veya retry topic'leri ile yönetilir. DLQ, maksimum retry sonrası mesajı izole etmek için kullanılır. Ayrıca poison message detection, visibility timeout ve backoff on requeue özellikleri önemlidir.

3.7 Retry policies by error type

Tüm hatalar için aynı retry politikasını uygulamak yanlış olur. Örneğin 4xx HTTP hataları (client error) genellikle retry gerektirmez; 5xx (server error) ve network timeout gibi transient hatalar için retry uygundur. Rate limit (429) durumlarında server'ın verdiği Retry‑After header'ı dikkate almalı ve agressive retry'den kaçınılmalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

Google / Exponential backoff tavsiyesi

Google Cloud API'leri ve SDK'ları, kilitlenmeyen backoff ve jitter kombinasyonlarını önerir. Global ölçekli servislerde istemcilerin aynı anda yeniden denemesini engellemek hayati önem taşır.

AWS SQS & Lambda — Visibility timeout ve DLQ

AWS SQS ile Lambda entegrasyonlarında visibility timeout ve maksimum retry sayısı kritik ayarlardır. İşlem başarısız olursa mesaj yeniden görünür hale gelir; belirlenen limita ulaşınca DLQ'ye gönderilir. Bu yapı geçmiş hataların incelenmesine ve manuel müdahaleye olanak tanır.

Stripe ve idempotency

Ödeme sistemleri gibi yan etkisi olan işlemlerde Stripe, idempotency key kullanımını zorunlu veya güçlü öneri olarak sunar. Böylece istemci bir isteği yeniden gönderse bile sunucu duplicate charge oluşturmaz.

Kafka stream processing retries

Kafka tüketicilerinde retry genelde topic tabanlıdır: işlenemeyen mesajlar retry topic'lerine aktarılır, oradan gecikmeli tüketim veya DLQ yoluyla yönetilir. Stateful stream işlemelerinde checkpointing ve offset management ile koordinasyon önemlidir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Transient hataların otomatik düzeltilmesi ve kullanıcı işlemlerinin başarıya ulaşma oranının artması
• Operasyonel müdahale gereksiniminin azalması
• İyi tasarlanmış backoff/jitter ile bağımlı servis üzerindeki baskının azalması

Sınırlamalar

• Kötü ayarlanmış retry çift taraflı yeniden denemeler ve thundering herd oluşturabilir
• Yan etkisi olan (non‑idempotent) işlemler için duplicate side‑effect riski
• Retry logları ve metrikleri olmadan RCA ve tuning zorlaşır

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Retry politikasını hata tipine göre ayırın: transient (5xx, timeouts) vs permanent (4xx).
• Exponential backoff + jitter kombinasyonunu varsayılan olarak kullanın.
• Retry Count ve max backoff limitleri belirleyin; DLQ ve manuel inceleme süreci kurun.

Idempotency ve side‑effect kontrolü

• Yan etkili işlemlerde idempotency key veya dedup store kullanın.
• Database tarafında unique constraint ve business‑level guards ile duplicate etkileri engelleyin.

Observability ve ölçümler

• Retry sayısı, fallback kullanımı, p95/p99 latency, DLQ oranları ve retry budget tüketimini metrikleyin.
• Alert'leri SLA hedeflerine göre kurun; retry spike'ları otomatik uyarı üretmelidir.

Test ve kaos

• Fault injection ile retry davranışını test edin; istisnai durumlarda nasıl tepki verdiğinizi doğrulayın.
• Load testing ile retry parametrelerinin sistem üzerindeki etkisini ölçün.

8. SIK YAPILAN HATALAR

• Retry'yı her hataya uygulamak — bazı hatalar retry ile düzelmez (ör. 400 Bad Request).
• Jitter kullanmamak — aynı anda binlerce istemci aynı anda yeniden denerse thundering herd oluşur.
• Idempotency kontrolü olmadan retry yapmak — duplicate yan etkiler riski.
• Centralized retry olmadan istemcilerin rastgele retry politikaları uygulaması — karmaşık davranış ve debugging zorluğu.

9. GELECEK TRENDLER

1. AI‑assisted retry tuning: Telemetriye dayalı otomatik eşik ve backoff optimizasyonu.
2. Policy as code: Retry politikalarının kod ve deklaratif yapı ile CI/CD içinde yönetilmesi.
3. Adaptive retry ve circuit coordination: Gerçek zamanlı sistem durumu ile retry davranışını dinamik değiştiren adaptive mekanizmalar.
4. Edge‑aware retries: Edge cihazlarda düşük kaynak tüketimli, lokal fallback ve senkronize retry stratejileri.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Retry her zaman gerekli mi?

   Hayır. Retry, transient hatalarda yardımcıdır. Client error (4xx) veya idempotency garantisi olmayan kritik işlemler için dikkatli düşünülmelidir.

2. 2. Exponential backoff ile jitter neden birlikte kullanılmalı?

   Backoff, yeniden denemeleri yavaşlatırken jitter, bu denemelerin istemciler arasında yayılmasını sağlayarak aynı anda yapılacak toplu denemeleri (thundering herd) engeller.

3. 3. DLQ ne zaman kullanılmalı?

   Bir mesaj veya istek birden fazla retry sonrası hâlâ işlenemiyorsa otomatik incelenme için DLQ'ye gönderilmelidir.

4. 4. Retry budget nedir ve neden önemli?

   Retry budget, sistem genelinde izin verilen retry miktarını sınırlayarak bağımlı servislere toplu baskıyı önler ve kaynakların tükenmesini engeller.

5. 5. İstemci ve sunucu taraflı retry birlikte kullanıldığında nelere dikkat etmek gerekir?

   Her iki taraftaki retry'lerin toplam etkisini göz önünde bulundurun; idempotency, retry budget ve koordinasyon ile çakışmayı önleyin.

6. 6. Hangi hatalarda retry yapılmamalı?

   Genelde 4xx client hatalarında tekrar denemek yerine hatanın kaynağını düzeltmek gerekir. Ayrıca authentication/authorization hatalarında retry anlamsızdır.

7. 7. Retry metrikleri nelerdir?

   Retry count, retry rate, fallback count, DLQ rate, p95/p99 latencies ve retry budget tüketimi temel metriklerdendir.

8. 8. Idempotency nasıl uygulanır?

   İsteğe unique id (idempotency key) ekleyin ve sunucuda işlenmiş id'leri saklayıp duplicate isteği ignore veya güvenli şekilde yanıtlayın. Transactional constraints ve unique indexes ile desteklenmelidir.

Anahtar Kavramlar

Exponential backoff

Deneme gecikmesinin katlanarak arttığı strateji.

Jitter

Retry zamanlarına rastgelelik ekleyerek koordineli patlamaları azaltma tekniği.

Retry budget

Sistem genelinde veya tenant seviyesinde izin verilen retry miktarını sınırlama mekanizması.

Dead Letter Queue (DLQ)

Maksimum retry sonrası başarısız mesajların saklandığı kuyruk.

Idempotency key

Bir isteğin birden fazla kez gönderilse bile yalnızca bir kere işlenmesini sağlayan benzersiz anahtar.

Öğrenme Yol Haritası

1. 0–1 ay: Retry temel kavramlarını öğrenin: fixed delay, exponential backoff, jitter ve DLQ.
2. 1–3 ay: Kütüphaneler (Resilience4j, Polly, Spring Retry) ile uygulamalar geliştirin; idempotency ve unique key uygulamalarını deneyin.
3. 3–6 ay: Distributed retry senaryoları, retry budget, gateway ve service mesh entegrasyonları üzerinde çalışın; DLQ süreçlerini kurup test edin.
4. 6–12 ay: Chaos engineering ve fault injection ile production‑benzeri ortamda retry tuning yapın; telemetry ve AI‑assisted optimizasyonları keşfedin.