Polly v8 ile .NET'te Retry: kaç kez kapıyı çalalım?

Bir kurye hikâyesi üzerinden Retry pattern'ini anlatan bu rehber, Polly v8'in `ResiliencePipeline` yaklaşımıyla HTTP çağrılarında retry, exponential backoff, jitter, timeout ve `Retry-After` desteğini adım adım kuruyor. Örnek, `Microsoft.Extensions.Http.Resilience` 10.0.0 paketiyle .NET 10 üzerinde Clean Architecture katmanlarına ayrılmış bir ürün okuma senaryosu kullanıyor.

Kilit noktalar

• `MaxRetryAttempts = 3` ilk denemeye ek 3 retry demektir; toplam en fazla 4 çalıştırma olur.
• Polly v8'de `Policy.Handle(...)` yerine `ResiliencePipeline` ve builder tabanlı options kullanılıyor; v7 örnekleri güncel değil.
• 200 ms tabanlı exponential backoff 200/400/800 ms üretir; jitter açıkken sıra her zaman artan olmayabilir.
• `HttpRetryStrategyOptions.ShouldRetryAfterHeader` ile 429 yanıtlarındaki `Retry-After` değeri bekleme süresi olarak kullanılabiliyor.
• Timeout, işlemin sunucuda gerçekleşmediğini kanıtlamaz; yazma komutlarında idempotency key gerekiyor.
• Gateway sözleşmesi "yok" (null) ile "teknik hata" (özel exception) durumlarını ayırıyor, böylece 503 hatası 404 gibi görünmüyor.

Article, başarısız bir işlemin ikinci denemede tutabileceği durumları anlatan basit benzetmeyle başlıyor ve bunu gerçek HTTP dayanıklılığına bağlıyor: 502, 503 ve 504 gibi geçici hatalar adayken, 400, 401, 403 ve 404 için retry yapmak yalnızca gereksiz yük üretiyor. Timeout'un işlemin sunucuda tamamlanmadığı anlamına gelmediğini, bu yüzden veri değiştiren komutlarda idempotency key gibi bir koruma gerektiğini vurguluyor.

Uygulama tarafında Polly v8'in eski `Policy.Handle(...).WaitAndRetryAsync(...)` API'sinden farklı olarak builder tabanlı `ResiliencePipeline` kurduğu anlatılıyor. `ShouldHandle`, `MaxRetryAttempts` (3 değeri 1 ilk deneme artı 3 retry, yani toplam 4 çalıştırma demek), `Delay`, `BackoffType`, `UseJitter`, `OnRetry` ve `HttpRetryStrategyOptions.ShouldRetryAfterHeader` gibi ayarlar örnekleniyor. `Microsoft.Extensions.Http.Resilience` 10.0.0 ile .NET 10 projesi, Application/Infrastructure ayrımı ve 503 → 503 → 200 senaryosunu üreten sahte bir Catalog API ile tamamlanıyor.

Gerçek dünyada kullanımı

• Ürün detaylarını harici bir Catalog API'sinden çeken ve kullanıcıya 503 göstermek yerine kısa bir backoff ile tekrar denemek isteyen bir e-ticaret endpoint'i.
• Ödeme ya da sipariş oluşturma gibi yazma komutlarını, timeout sonrası çift kayıt oluşmaması için idempotency key ile tekrar deneyen bir servis.
• Gece çalışan veri içe aktarma işlerinde toplu isteklerin hız sınırına takıldığında `Retry-After` başlığına uyarak bekleyen bir worker.
• Mikroservisler arası HttpClient çağrılarında `Microsoft.Extensions.Http.Resilience` ile merkezi bir dayanıklılık pipeline'ı tanımlayan bir ekip.

Neden önemli

Retry yanlış yapılandırıldığında hatayı düzeltmek yerine yükü çoğaltır; bu rehber hangi hataların denenebilir olduğunu, bekleme süresinin nasıl ölçekleneceğini ve yazma işlemlerinde çift etkiyi nasıl engelleyeceğinizi ayırt etmenizi sağlıyor.

Benzer haberler

• C# 14 extension member'ları: derleyicinin uyarmadığı gölgeleme hatasıDVDEV Community: #csharp2 gün önce
• .NET 10 + Pinecone: vektör veritabanı entegrasyonuDVDEV Community: #dotnet3 gün önce
• C# interface'lerinde collection dönüş tipleri: interface, view ve snapshot farkıDLNick Cosentino (Dev Leader)3 gün önce