Retry-Logik bezeichnet den Mechanismus in einem automatisierten System, der bei einem fehlgeschlagenen Verarbeitungsschritt – z. B. einem nicht erreichbaren API-Endpunkt, einem Netzwerkfehler oder einer vorübergehenden Systemüberlastung – den fehlgeschlagenen Schritt nach einer definierten Wartezeit automatisch erneut versucht. Anstatt sofort mit einem Fehler abzubrechen, gibt die Retry-Logik dem System Zeit, sich zu erholen, und wiederholt den Versuch – meist mehrfach mit wachsenden Wartezeiten.
Retry-Logik ist ein grundlegendes Resilienzmuster in verteilten Systemen: Temporäre Fehler sind in realen Umgebungen unvermeidlich – Netzwerkpakete gehen verloren, externe APIs sind kurzzeitig überlastet, Datenbanken sind im Wartungsfenster. Retry-Logik macht automatisierte Prozesse gegenüber diesen unvermeidlichen, temporären Störungen robust.
Ablauf einer typischen Retry-Sequenz
Exponential Backoff – Retry mit wachsender Wartezeit
Versuch 1API-Call schlägt fehl → Fehler 503 (Service Unavailable)
Warten 1sKurze Pause, um der API Zeit zur Erholung zu geben
Versuch 2Erneuter API-Call → schlägt wieder fehl
Warten 4sWartezeit verdoppelt (Exponential Backoff)
Versuch 3Erneuter API-Call → schlägt wieder fehl
Warten 16sWartezeit erneut verdoppelt
Versuch 4API antwortet erfolgreich → Prozess wird fortgesetzt
Retry-Strategien
- Immediate Retry: Sofortiger Wiederholungsversuch ohne Wartezeit – nur bei sehr kurzen, transienten Fehlern sinnvoll; kann externe Systeme zusätzlich belasten
- Fixed Delay: Feste Wartezeit zwischen allen Versuchen (z. B. immer 5 Sekunden) – einfach, aber nicht optimal bei anhaltender Überlastung
- Exponential Backoff: Wartezeit verdoppelt sich nach jedem Fehlschlag (1s, 2s, 4s, 8s, 16s…) – reduziert die Last auf das fehlerhafte System schrittweise
- Exponential Backoff mit Jitter: Wie Exponential Backoff, aber mit zufälliger Variation der Wartezeit – verhindert, dass viele Clients gleichzeitig denselben fehlerhaften Dienst anstürmen
Wann Retry-Logik nicht hilft
Retry-Logik ist ausschließlich für temporäre Fehler sinnvoll – Situationen, in denen ein Wiederholungsversuch nach kurzer Wartezeit erfolgreich sein kann. Bei permanenten Fehlern – ungültige Dateneingaben, fehlende Berechtigungen, nicht existierende Ressourcen – wird ein Retry-Mechanismus niemals erfolgreich sein und produziert nur unnötigen Aufwand. Eine gute Retry-Logik unterscheidet zwischen temporären und permanenten Fehlern und gibt nur bei temporären nach.
Praxisbeispiel
Ein Automatisierungsworkflow verarbeitet täglich 2.000 Rechnungen und überträgt jede an eine Buchhaltungs-API. Die API ist gelegentlich kurzzeitig nicht verfügbar – typischerweise für 10–30 Sekunden nach Updates. Ohne Retry-Logik: Jede Rechnung, die in dieser Zeit verarbeitet wird, scheitert mit einem Fehler – manueller Eingriff nötig. Mit Exponential-Backoff-Retry (max. 5 Versuche, Startwartezeit 2 Sekunden): Die API erholt sich in der Regel innerhalb der zweiten oder dritten Wiederholung. 99,7 Prozent aller Rechnungen werden ohne menschlichen Eingriff erfolgreich übertragen. Nur die restlichen 0,3 Prozent landen in der Dead Letter Queue zur manuellen Bearbeitung.
