Retry / Backoff
Einleitung
Retry behandelt transiente Fehler bei Remote-Calls.
Statt sofort zu scheitern, wird der Aufruf wiederholt.
Backoff steuert die Wartezeit zwischen Wiederholungen, um:
- Lastspitzen zu vermeiden
- Systeme nicht weiter zu destabilisieren
Grundsatz:
Retry ist nur sicher, wenn die Operation idempotent ist.
Einordnung
Retry / Backoff ist ein Micro-Pattern für Resilienz.
Typische Einsatzfelder:
- Microservices
- SOA
- Event-Driven Architectures
- Externe API-Calls
Es wirkt auf der Kommunikationsebene, nicht auf Prozessebene.
Grundprinzip
Wann Retry sinnvoll ist
Retry eignet sich für:
- Timeout
- Netzwerk-Glitches
- kurzzeitige Überlast
- 5xx-Fehler
Retry ist nicht sinnvoll bei:
- 4xx-Fehlern
- Validierungsfehlern
- fachlichen Ablehnungen
Retry darf keine Logik ersetzen.
Backoff-Strategien
1️⃣ Fixed Delay
Konstante Wartezeit.
Einfach, aber riskant bei vielen Clients.
2️⃣ Exponential Backoff
Wartezeit wächst exponentiell:
1s → 2s → 4s → 8s …
Reduziert Last bei längerem Ausfall.
3️⃣ Jitter
Zufällige Variation der Wartezeit.
Verhindert:
Synchronisierte Retry-Stürme
Empfohlene Praxis:
Exponential Backoff + Jitter.
Gefahren
1️⃣ Retry Storm
Viele Clients retryen gleichzeitig:
- Last steigt weiter
- System kollabiert schneller
Retry kann Fehler verstärken.
2️⃣ Nicht-idempotente Operationen
Beispiel:
- Zahlung erneut ausführen
- Bestellung doppelt anlegen
Ohne Idempotenz → doppelte Seiteneffekte.
3️⃣ Zu viele Retries
Mehr Versuche ≠ höhere Zuverlässigkeit.
Besser:
- wenige, kontrollierte Retries
- klare Abbruchstrategie
Zusammenspiel mit anderen Patterns
Circuit Breaker
Circuit Breaker schützt vor endlosen Retries.
Retry sollte:
- vor dem Breaker begrenzt sein
- Breaker-Zustand respektieren
Idempotency
Retry ohne Idempotenz ist gefährlich.
Rate Limiting
Retry darf Rate Limits nicht weiter triggern.
Dead Letter Queue (bei Messaging)
Nach maximalen Retries:
- Event in DLQ verschieben
- nicht endlos wiederholen
Vorteile
- Erhöht Erfolgsrate bei transienten Fehlern
- Automatisiert Fehlerbehandlung
- Reduziert manuelle Eingriffe
Nachteile
- Kann Last verstärken
- Erhöht Komplexität
- Gefährlich ohne Idempotenz
Wann sinnvoll?
- Instabile Netzwerke
- Cloud-Umgebungen
- Externe APIs
- Kurzzeitige Lastspitzen
Wann nicht sinnvoll?
- Fachliche Fehler
- Nicht-idempotente Operationen
- Persistente Systemstörungen
Strategische Perspektive
Retry ist:
- kein Ersatz für Architektur
- kein Ersatz für Skalierung
- kein Ersatz für Fehleranalyse
Es ist ein:
temporärer Stabilitätsmechanismus.
Falsch konfiguriert wird es zum Brandbeschleuniger.
Fazit
Retry / Backoff:
- behandelt transiente Fehler
- braucht Idempotenz
- muss begrenzt sein
- sollte mit Circuit Breaker kombiniert werden
Ohne Jitter entstehen synchronisierte Fehlerwellen.
Mit Jitter und Disziplin entsteht kontrollierte Resilienz.