Üretimde “küçük bir gecikme” çoğu zaman tek başına outage üretmez. Outage’ı büyüten şey genelde retry davranışıdır. Çünkü retry, görünüşte “dayanıklılık” gibi dursa da yanlış yerde ve yanlış bütçeyle uygulanırsa sistemi daha fazla yükler.
Bu yazı üç kavramı netleştirir:
- Timeout budget: bir isteğin toplam süre bütçesi
- Retry budget: retry için ayrılan ek deneme hakkı
- Latency amplification: küçük bir gecikmenin, sistemin tamamında büyümesi
1) Retry neden outage’ı büyütür?
Basit örnek:
- Servis B’nin normal p95’i 80ms
- Bir sorun oldu ve p95 400ms’e çıktı
- Servis A, 300ms timeout + 2 retry ile konfigüre
Bu durumda A, B’ye daha çok trafik üretir; B zaten yavaşladığı için daha da yavaşlar. Bu bir “kısır döngü”dür:
- Latency artar
- Timeout/retry tetiklenir
- Trafik artar
- Latency daha da artar
2) Timeout budget: zinciri baştan tasarla
Timeout’u “tek bir sayı” gibi düşünmek hata. Dağıtık isteklerde timeout bütçesi parçalanır:
- Client toplam bütçesi (ör. 800ms)
- Gateway/edge bütçesi (ör. 700ms)
- App bütçesi (ör. 600ms)
- Downstream çağrılar (ör. 2x 250ms)
Pratik kural:
- Üst katman timeout’u, alt katman timeout’undan daha büyük olmalı.
- Alt katmanda “deadline propagation” olmalı (kalan süreyi downstream’e taşı).
3) Retry budget: “kaç kere” değil “hangi durumda”?
Üretimde güvenli retry şu koşullarda anlamlıdır:
- İstek idempotent ise (GET gibi) veya idempotency key ile korunuyorsa
- Hata tipi geçici ise (ör. connection reset)
- Backoff + jitter varsa
- Sistem satüre değilse (retry budget dinamik olarak kısılır)
Sadece “2 retry” demek yetersizdir. Önemli olan:
- Hangi hata kodlarında retry?
- Hangi endpoint’lerde retry?
- Hangi client segmenti retry?
4) Latency amplification’ı sınırlayan guardrail’ler
Sahada en çok işe yarayan guardrail seti:
- Backoff + jitter: retry’ları dağıtır
- Concurrency limit: aynı anda kaç iş alacağını sınırlar
- Queue + drop policy: kuyruğu sonsuz büyütmez
- Circuit breaker: hızlı fail ile “sistem nefesi” sağlar
- Load shedding: düşük öncelikliyi erken reddeder (429/503)
Bu guardrail’ler yoksa retry, “herkes aynı anda tekrar dene” davranışına dönüşür.
5) Incident sırasında pratik müdahale
Retry fırtınası şüphesi varsa:
- Retry’ı azalt veya kapat (özellikle non-idempotent işlemlerde)
- Timeout’u “kısaltmak” yerine önce deadline propagation kontrol et
- Concurrency limit’i düşür, kuyruğu kontrol altına al
- 429/503 oranını izle: erken fail, toplam hasarı azaltabilir
- Client tarafında exponential backoff + jitter doğrula
Buradaki amaç “daha çok request’i zorla geçirmek” değil; sistemin genel sağlığını koruyup stabil hale getirmektir.
Retry doğru kurgulanırsa dayanıklılık üretir. Yanlış kurgulanırsa outage’ı büyütür. Üretimde başarı; timeout budget, retry budget ve backpressure’ı birlikte tasarlayabilmektir.