Giriş
Retry-After Parametresi
REST çağrılarında sunucu HTTP 429 (Too Many Requests) veya 503 (Service Unavailable) gelse bile
HTTP 429 (Too Many Requests) or 503 (Service Unavailable) should trigger backoff, not immediate retry. The Retry-After header tells you explicitly when to try again — actually respect it. A 500 might be transient or might be a bug that'll fail identically every time; you need application context to tell the difference.
Retry İşlemini Kim Yapmalı
1. Her servis kendisi Retry işlemini gerçekleştirebilir
2. Ortak bir Retry servisi olabilir. Açıklaması
şöyle
... it removes the retry complexity from all microservices, and places it in a single retry microservice. The retry microservice’s job is to track and action all retries. This microservice receives an event, writing it to its own topics with both the event to retry and the timestamp to retry that event. It then pushes out these retry events once their timestamp has been reached.
Retry Verisi Nerede Saklanmalı
1. Kafka, AMQP gibi bir kuyrukta saklanabilir
2. Veri tabanında saklanabilir
Retry Detayları
Sistem içinde hata olsa bile işlem belli bir süre sonra tekrar denenir. Retry yönteminde dikkat edilecek noktalar şöyle
1. Retry sayısı
2. Retry aralığı (back off süresi)
3. Tüm denemeler başarısız olursa ne yapılacağı
4. Retry işleminin stateless veya stateful olacağı
5. Retry 'ın çağırdığı şilemin Idempotent Receiver olması.
Idempotency Nedir yazısına bakabilirsiniz.
Bazen Retry alt yapısını bizim kodlamamız gerekir, eğer şanslıysak kullandığımız alt yapı bu yeteneği bütünüyle veya kısmen de sağlıyor olabilir.
Not : Bu konuda okunması gereken bir yaz
burada
Retry Storms
Elimizde bir servis çağrısı dizisi
olsun
A -> B -> C -> D
ve D
çalışmıyor olsun. Bu durum Retry Storm sebebidir. Açıklaması
şöyle
Now imagine that each service has a retry policy installed which performs up to 3 retries on failed calls (a total of 3+1 requests). Think about what happens if D goes down, and this failure is propagated all the way back up the call chain:
C calls D 4x more
B calls C 4x more
A calls B 4x more
The traffic D receives might be as much as 64 times (!!) that of normal levels. And this is happening when D is already unhealthy — likely impairing it further.
Sounds bad, but the real problem is that these traffic increases grow exponentially. If K is the number of attempts made per call at each node, then the magnitude of the increase in call volume at depth N in the call graph is K^N. This behavior is known as a retry storm, and it can compound minor outages into major cascading failures.
Retry İle İlgili Parametreler
Açıklaması
şöyle. Eğer bu parametreleri atlarsak failure durumu outage durumuna dönebilir.
Retries can amplify failures into outages. Use backoff, circuit breakers, idempotency, load shedding, and observability to keep systems stable under pressure.
1. Retry Sayısı
Mantıklı bir üst sınıf vermekte fayda var. Yoksa işlem/mesaj sonsuz döngü şeklinde sürekli tekrar tekrar kaynak tüketir.
2. Retry Aralığı
Açıklaması
şöyle. Sabit, rastgele veya artan aralıklar kullanılabilir.
You retry few times hoping to get a response, with a fixed, random or exponential wait period in between each attempt and eventually give up to try in the next poll cycle.
Burada
Exponential backoff with jitter öneriliyor. Açıklaması
şöyle.
First retry after 100ms, second after 200ms, third after 400ms. The jitter — randomizing each delay by ±25% or so — prevents the thundering herd where all clients retry in lockstep. Without jitter, you've built a periodic self-DDoS that hits your own service like a metronome.
ÖrnekJava kullanıyorsak elimizde şöyle bir kod
olsun .
ScheduledExecutorService service = Executors.newScheduledThreadPool(5);
Şöyle
yaparız.
service.execute(task);
...
service.schedule(task, 20, TimeUnit.SECONDS);//retry
ÖrnekJava kullanıyorsak elimizde şöyle bir kod
olsun . java.util.Timer kullanıyoruz
Timer timer = new Timer();
Şöyle
yaparız.
timer.schedule(task, 20);
3. Tüm denemeler başarısız olursa ne yapılacağı
Aslında iki tane seçenek var
2. İşlem/mesaj tamamen çöpe atılır
4. Retry işleminin stateless veya stateful olacağı
- Stateless retry işlemlerinden retry mekanizması aynı thread içinde N defa işlemi dener. Thread bu N deneme süresince başka bir işle uğraşmaz.
- Stateful retry işlemlerinden retry mekanizması aynı thread içinde işlemi dener. Eğer başarısız ise, thread başka bir işe geri döner. Yani bloke olmaz. Retry zamanı gelince tekrar dener.
Örnek - Resilience4j
public List<CompanyDto> searchCompanyByName(String name) {
RetryConfig retryConfig =
RetryConfig.custom().maxAttempts(4).waitDuration(Duration.of(2, SECONDS)).build();
RetryRegistry retryRegistry = RetryRegistry.of(retryConfig);
Retry retryConfiguration = retryRegistry.retry("companySearchService", retryConfig);
Supplier<List> companiesSupplier = () -> companyRepository.findAllByName(name);
Supplier<List> retryingCompaniesSearch =
Retry.decorateSupplier(retryConfiguration, companiesSupplier);
List<CompanyDto> companyDtos = new ArrayList<>();
List companies = retryingCompaniesSearch.get();
for(Company company : companies) {
CompanyDto companyDto = new CompanyDto(company.getName(), company.getType(),
company.getCity(), company.getState(), company.getDescription());
companyDtos.add(companyDto);
}
return companyDtos;
}
While using resilience4j-retry library, you can register a custom global RetryConfig with a RetryRegistry builder. Use this registry to build a Retry.
In the above method, we first create RetryConfig. We create a RetryRegistry and add RetryConfig in this registry. Then when we create our call to fetch a list of companies. We decorate this call with retryConfiguration.
RetryConfig açıklaması
şöyle
Customizations with Resilience4j-Retry
RetryConfig offers different customization:
1. maxAttempts — 3 is the default number of attempts for retries.
2. waitDuration — a fixed wait duration between each retry attempt.
3. intervalFunction — a function to modify the waiting interval after a failure.
4. retryOnResultPredicate — configures a predicate that evaluates if a result should be retried.
5. retryExceptions — Configures a list of throwable classes that are used for retrying
6. ignoreExceptions — Configures a list of throwable classes that are ignored
7. failAfterMaxRetries — A boolean to enable or disable throwing of MaxRetriesExceededException when the Retry has reached the configured maxAttempts
Retry Design Pattern ve Circuit Breaker Pattern
Aslında birbirlerini tamamlıyorlar. Circuit Breaker eğer bir sistemin çalışmadığını anlarsa Retry işlemine girmeden direkt bir cevap döner. Açıklaması
şöyle.
I would like to mention, a subtle difference with "Circuit Breaker" pattern, which is actually one level up. It has an implicit Retry but also prevents further communication until the remote service is available and responds with a test call. This strategy is recommended when you expect services to be unavailable for a longer duration whereas "Retry" is recommended for transient failures (short duration or temporary failures).
Idempotency
Açıklaması
şöyle. Eğer bu parametreleri atlarsak failure durumu outage durumuna dönebilir.
You need idempotency keys, client-generated request IDs that let the server recognize duplicates. Without this, your retry logic becomes a data corruption engine. I've seen double charges, duplicate emails, inventory counts that drifted further from reality with each retry.
The Retry Budget
SRE teams talk about error budgets — how much failure you can tolerate before breaking SLOs. Same logic applies to retries. You need a retry budget: a system-wide cap on in-flight retries.
When Retries Aren't Enough
Uncomfortable question: what happens when the system is genuinely overloaded and backing off won't help?
You have to shed load.
The server needs to signal "I cannot handle this" instead of accepting requests into a bottomless queue. Return errors. Return them fast. Let clients fail quickly and show degraded UI or route to a fallback. This requires killing the instinct to "handle everything" — sometimes dropping requests is the right move to keep the system functional for anyone at all.
Doğası Gereği Retry Olması Gereken İşlemler
Bazı sistemlerin doğasında Retry vardır. Karşı sistemden bir cevap dönmüyorsa, kullanılan alt yapı, iletişim ağı güvenilir değilse ister istemez Retry benzeri bir çözüm sistemde kullanılmaya başlanıyor.
Örnek
Bir sistemde UDP kullanıldığı için mesajlar kaybolabiliyordu. "Transmission Queue" bileşeninde her mesaj aynı birincil anahtar ile N defa tekrar edilecek şekilde bir çözüm geliştirildi. Böylece Retry örüntüsü aslında bir nevi gerçekleştirilmiş oldu.
