# Kritik Sistemlerde Güvenli Yeniden Deneme Tasarımı

> Yeniden deneme ancak geçici hata, idempotency, toplam zaman bütçesi ve kuyruk sınırları birlikte tanımlandığında güvenli bir hata toleransı mekanizmasıdır.

- Author: Muhammet Ali Köker
- Language: tr
- Canonical: https://alikoker.com.tr/kritik-sistemlerde-guvenli-retry-tasarimi
- Translation: https://alikoker.com.tr/en/safe-retry-design-in-critical-systems
- Published: 2026-08-02T12:00:00+03:00
- Modified: 2026-09-02T13:23:29+03:00
- Verified: 2026-08-07T11:00:00+03:00
- Type: article

Üretimde yeniden deneme kaynaklı arızaların çoğu “kaç kez deneyelim?” sorusundan başlamıyor; işlemin ilk denemede gerçekten başarısız olup olmadığının bilinmemesinden başlıyor. Özellikle yazma çağrısında bağlantı commit çevresinde koparsa istemci sonucu belirsiz bir işlemle karşı karşıya kalır ve aynı isteği körlemesine tekrarlamak ikinci bir yan etki üretebilir.

Bu nedenle yeniden deneme politikasını istisna listesi olarak değil, hata sınıfı + idempotency + zaman bütçesi + kapasite sınırı sözleşmesi olarak tasarlıyorum. Geçici ağ hatası ile doğrulama hatasının, commit öncesi bağlantı kaybı ile commit sonrası belirsizliğin aynı deneme politikasına girmemesi gerekir.

## Hataları Yeniden Denenebilirliğe Göre Ayırmak

Her hata geçici değildir. Bağlantı kurulamadı, servis geçici olarak kullanılamıyor veya kilitlenme nedeniyle transaction geri alındı gibi durumlar sınırlı yeniden denemeye uygun olabilir. Buna karşılık doğrulama hatası, yetki reddi, şema uyumsuzluğu, kısıt ihlali veya desteklenmeyen veri biçimi aynı girdide tekrarlandığında genellikle aynı sonucu üretir.

Güvenilir hata modeli en az şu ayrımı yapmalıdır:

- Geçici altyapı hatası
- Aşırı yük veya kota hatası
- Açıkça rollback edilmiş transaction
- Kalıcı iş kuralı veya veri hatası
- Kimlik doğrulama ve yetkilendirme hatası
- Sonucu belirsiz yazma işlemi

Istisna sınıfı tek başına yeterli olmayabilir. Aynı ağ hatası bağlantı kurulmadan önce oluştuğunda güvenli, commit isteği gönderildikten sonra oluştuğunda belirsiz sonuçlu olabilir.

## İdempotency ve Belirsiz Commit

Bir yazma işlemi commit sırasında bağlantısını kaybederse istemci işlemin uygulanıp uygulanmadığını kesin olarak bilemeyebilir. Kör yeniden deneme yinelenen kayıt veya iki kez gerçekleştirilen dış etki üretebilir.

Yeniden denenen yazmalar aşağıdaki mekanizmalardan biriyle korunmalıdır:

- İstemci tarafından üretilen değişmez işlem anahtarı
- İş anahtarı üzerinde unique kısıt
- Yinelenen kayıtları tekilleştirme tablosu veya idempotency kaydı
- Durum geçişinin koşullu güncellenmesi
- Aynı girdide aynı hedef adıyla atomik yayınlama

```sql
INSERT INTO payment_request(request_key, account_id, amount)
VALUES (?, ?, ?)
ON DUPLICATE KEY UPDATE request_key = request_key;
```

Bu örnek tek başına bütün iş akışını idempotent yapmaz. Aynı transaction içindeki yan etkilerin ve harici servis çağrılarının da aynı işlem anahtarıyla ilişkilendirilmesi gerekir.

## Backoff ve Jitter

Sabit aralıkla yeniden deneme yapan binlerce istemci, servis yeniden erişilebilir olduğunda aynı anda istek göndererek yeni bir aşırı yük dalgası oluşturabilir. Üstel backoff bekleme aralığını her denemede büyütür:

```text
delay_n = min(maxDelay, baseDelay · 2^n)
```

[Jitter](/wiki/jitter), istemcilerin aynı anda uyanmasını önlemek için bu gecikmeye kontrollü rastgelelik ekler. Full jitter yaklaşımında örnek bekleme:

```text
delay_n = random(0, min(maxDelay, baseDelay · 2^n))
```

Rastgelelik kriptografik olmak zorunda değildir; ancak test edilebilirlik için üretim stratejisi soyutlanmalı ve birim testlerinde deterministik kaynak kullanılabilmelidir.

## Yeniden deneme Bütçesi ve Son Tarih

Alt katmanların her biri bağımsız üç yeniden deneme yaptığında çağrı zinciri geometrik olarak büyüyebilir. İstemci, API geçidi, servis, veri erişim katmanı ve sürücü ayrı ayrı deniyorsa tek kullanıcı işlemi çok sayıda fiziksel isteğe dönüşür.

Bu nedenle çağrı başına ortak bir son tarih taşınmalıdır:

```text
remaining = deadline - monotonicNow
attemptTimeout < remaining
```

Deneme sayısı, toplam süre ve üretilen ek yük birlikte sınırlandırılmalıdır. Son denemeyi başlatacak kadar zaman kalmamışsa yeni bir istek göndermek yerine kontrollü hata dönmek daha doğrudur.

## Geri basınç ve Circuit Breaker

Yeniden deneme, kapasite üretmez. Servis kalıcı olarak doygunsa yeniden denemeler kuyruk ve [bağlantı havuzu](/wiki/connection-pool) baskısını artırır. Sınırlı kuyruk, semaphore, bağlantı havuzu sınırı ve yük reddetme politikası yeniden deneme tasarımının parçasıdır.

[Circuit breaker](/wiki/circuit-breaker) belirli hata oranında yeni çağrıları kısa süreli engelleyebilir. Ancak circuit breaker veri doğrulama hatalarıyla değil, hedef sistemin erişilebilirliğini temsil eden hata sınıflarıyla beslenmelidir. Half-open aşamasında sınırlı sayıda deneme çağrısına izin verilmesi gerekir; bütün bekleyen isteklerin aynı anda geçirilmesi yeni bir yük darbesi oluşturur.

## Kuyruk Tabanlı İş Akışları

Mesajlaşma sistemlerinde teslimat çoğu zaman en az bir kez gerçekleşir. Tüketici, işlem tamamlandıktan sonra onay vermeli; fakat onay kaybında aynı mesajın yeniden gelebileceğini kabul etmelidir. Zehirli mesajların sonsuz döngüye girmemesi için deneme sayısı veya yaş sınırı sonunda dead-letter kuyruğuna yönlendirme yapılmalıdır.

Yeniden deneme kaydı en az şu alanları taşımalıdır:

- İşlem anahtarı
- Deneme sayısı
- İlk ve son deneme zamanı
- Son hata sınıfı
- Bir sonraki deneme zamanı
- Mutlak son tarih
- Nihai durum

## Gözlemlenebilirlik

Yalnız toplam hata sayısı izlenmemelidir. İlk denemede başarı, yeniden deneme sonrası başarı, tükenen yeniden deneme, ortalama deneme sayısı, yeniden deneme kaynaklı ek trafik, bekleme süresi ve hata sınıfı ayrı ölçülmelidir. Loglar işlem anahtarını taşımalı; parola, token, kişisel veri veya tam veri yükü içermemelidir.

## Güvenli Tasarım Sözleşmesi

Kritik sistemde yeniden deneme şu koşullar sağlandığında kullanılmalıdır:

1. Hata geçici olarak sınıflandırılmıştır.
2. İşlem idempotenttir veya yinelenme denetlenmektedir.
3. Deneme sayısı ve toplam süre sınırlıdır.
4. Backoff ve jitter uygulanmaktadır.
5. Kuyruk, bağlantı ve eşzamanlılık sınırları korunmaktadır.
6. Belirsiz commit sonucu ayrı ele alınmaktadır.
7. Başarısızlığın nihai iş akışı tanımlıdır.

Güvenli yeniden deneme mekanizmasının başarı ölçütü “sonunda çalıştı” değildir. Ek trafik, toplam gecikme, kuyruk büyümesi ve yinelenen yan etkiler kontrol altında kalırken geçici hatadan kurtulabiliyorsa mekanizma işe yarar. Bu sınırlar yoksa yeniden deneme hata toleransı değil, arızayı çoğaltan bir yük üreticisidir.

## Yeniden Deneme Sonrası Yan Etkiler

Yeniden deneme kararı; kalıcı çıktının görünürlüğü, yeniden başlatılabilir ilerleme ve taşıma katmanındaki teslim semantiğiyle birlikte değerlendirilir: [atomik yayınlama](/dosya-islemede-atomik-yayinlama), [yeniden başlatılabilir backfill](/tarih-bolumlu-verilerde-dayanikli-backfill), [mesajlaşma](/netmq-ile-brokerless-mesajlasma).

## Yeniden Deneme Politikasının Kanıt Sınırı

Buradaki üç ana yapı farklı kaynaklara dayanır. HTTP yöntemlerinin idempotent olup olmadığına ilişkin protokol semantiği [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html) tarafından tanımlanır. Exponential backoff ve jitter'ın senkron yeniden deneme dalgalarını azaltma amacı AWS'nin *Exponential Backoff and Jitter* çalışmasında somutlaştırılır. Retry budget, overload ve güvenilirlik düşüncesi ise SRE literatüründeki kapasite/failure yaklaşımıyla ilişkilidir.

Bunlardan “her hata tekrar denenmelidir” sonucu çıkmaz. Tam tersine retry kararı; hatanın geçici olup olmadığına, işlemin idempotency sözleşmesine, kalan deadline'a ve sistemin mevcut yüküne bağlı türetilmiş bir mühendislik kararıdır. Yazı bu sınırı özellikle korur: backoff bir zamanlama mekanizmasıdır; güvenli yan etki, yetkilendirme veya transaction garantisi değildir.

## Kaynakça

- Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy (eds.). (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. [URL](https://sre.google/sre-book/table-of-contents/)

- Marc Brooker. (2015). Exponential Backoff and Jitter. AWS Architecture Blog. [URL](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)

- Roy T. Fielding; Mark Nottingham; Julian Reschke. (2022). HTTP Semantics. RFC Editor. [doi:10.17487/RFC9110](https://doi.org/10.17487/RFC9110)

## Bu Çalışmaya Atıf

Köker, M. A. (2026). Kritik Sistemlerde Güvenli Yeniden Deneme Tasarımı. alikoker.com.tr. https://alikoker.com.tr/kritik-sistemlerde-guvenli-retry-tasarimi

- BibTeX: https://alikoker.com.tr/kritik-sistemlerde-guvenli-retry-tasarimi.bib
- RIS: https://alikoker.com.tr/kritik-sistemlerde-guvenli-retry-tasarimi.ris
- CSL-JSON: https://alikoker.com.tr/kritik-sistemlerde-guvenli-retry-tasarimi.csl.json