Retries & Backoff: So verhinderst du Thundering Herd.
Retries und Exponential Backoff: Thundering Herd verhindern
Retry-Logik, die falsch implementiert ist, kann einen Ausfall vervielfachen statt abzumildern.
Das Problem mit naivem Retry
Wenn 1000 Clients alle gleichzeitig einen fehlgeschlagenen Request wiederholen – sofort, zur gleichen Zeit – trifft das den Server mit einer Last-Welle. Der Server, der vielleicht gerade dabei war sich zu erholen, wird nochmal überlastet. Das nennt sich Thundering Herd.
Die Lösung: Exponential Backoff mit Jitter.
Exponential Backoff
Warte nach dem ersten Fehler 1s, nach dem zweiten 2s, nach dem dritten 4s, nach dem vierten 8s. Jeder Retry wartet doppelt so lang wie der vorherige. Das gibt dem Server Zeit, sich zu erholen.
Jitter
Wenn alle Clients dasselbe Exponential-Backoff-Muster nutzen, retrien sie trotzdem synchron. Jitter fügt eine zufällige Komponente hinzu: statt genau 4s wartet jeder Client zwischen 2s und 6s. Das verteilt die Last.
Full Jitter: sleep = random_between(0, base * 2^attempt). Equal Jitter: sleep = base * 2^attempt / 2 + random_between(0, base * 2^attempt / 2).
Circuit Breaker
Nach x aufeinanderfolgenden Fehlern: keine weiteren Retries für eine definierte Zeit. Der Circuit "öffnet" sich. Das verhindert, dass ein dauerhaft ausgefallener Service mit Retries bombardiert wird.
Nach der Pause: ein einzelner Test-Request ("Half-Open" State). Wenn der erfolgreich ist – Circuit "schließt" wieder.
Checkliste Retries
Exponential Backoff implementiert
Jitter hinzugefügt
Maximum Retry Count definiert
Circuit Breaker für kritische externe Dependencies
Retry-Verhalten in Tests verifiziert
Monitoring auf Retry-Rate (hohe Retry-Rate = Signal für Probleme)
Retry-Strategie für eure Integrationen?
markom.digital implementiert robuste Retry- und Circuit-Breaker-Mechanismen für kritische Schnittstellen.
