Was ist ein Retry-Mechanismus?

Ein Retry-Mechanismus ist eine automatische Wiederholung einer Aktion nach einem Fehlschlag. Wenn eine API-Anfrage einen Fehler zurückgibt oder eine Verbindung abbricht, versucht der Retry-Mechanismus die Aktion nach einer definierten Wartezeit erneut. Das verhindert, dass einzelne, temporäre Fehler eine gesamte Automation zum Stillstand bringen.

Temporäre Fehler sind in verteilten Systemen normal. Eine API ist kurz überlastet und gibt einen 503-Fehler zurück. Eine Netzwerkverbindung bricht für 2 Sekunden ab. Ein Datenbankserver ist für einen Augenblick beschäftigt. Alle diese Situationen sind vorübergehend. Ein Retry 30 Sekunden später wird meistens erfolgreich sein.

Retry-Strategien

Einfaches Retry: Nach einem Fehler sofort oder nach kurzer Pause noch einmal versuchen. Einfach, aber bei anhaltenden Problemen ineffizient.

Fixed Delay: Zwischen jedem Versuch wird dieselbe Wartezeit eingelegt. Besser, aber bei langsamerer Erholung des Zielsystems immer noch suboptimal.

Exponential Backoff: Die Wartezeit verdoppelt sich mit jedem Fehlversuch. Erster Retry nach 30 Sekunden, zweiter nach 60, dritter nach 120, vierter nach 240 Sekunden. Das gibt dem Zielsystem mehr Zeit zur Erholung und vermeidet übermäßigen Traffic auf einem bereits überlasteten System.

Exponential Backoff mit Jitter: Wie Exponential Backoff, aber die Wartezeit wird um einen zufälligen Wert variiert. Warum? Wenn 1000 Clients alle gleichzeitig nach demselben Muster retries, treffen sie das Zielsystem wieder gleichzeitig. Jitter verhindert dieses Thundering-Herd-Problem.

Wann sollte nicht retried werden?

Nicht alle Fehler sind es wert, wiederholt zu werden. 4xx-Fehler (400 Bad Request, 404 Not Found, 422 Unprocessable Entity) sind meistens Client-Fehler, also Fehler in der Anfrage selbst. Ein Retry wird dasselbe Ergebnis liefern, weil sich an der Anfrage nichts geändert hat. Diese Fehler sollten direkt in die Dead Letter Queue oder zur Fehlerbehandlung weitergeleitet werden.

5xx-Fehler (500, 502, 503) sind Serverfehler, also Fehler auf der Seite des Zielsystems. Hier macht ein Retry nach einiger Zeit Sinn.

Auch nach einem bestimmten Zeitfenster sollten Retries aufhören. Eine Bestellübertragung, die nach 24 Stunden immer noch nicht funktioniert, sollte nicht ewig wiederholt werden, sondern eine manuelle Intervention auslösen.

Im Rahmen unserer Automation-Projekte konfigurieren wir Retry-Strategien für jeden Integrationspunkt individuell. Beim Termin besprechen wir, welche deiner Schnittstellen die kritischsten Retry-Anforderungen haben.