Die Retry-Logik (englisch für Wiederholungslogik) wiederholt fehlgeschlagene Operationen automatisch, wenn der Fehler vorübergehend ist (transient). Typische Fälle sind Netzwerk-Timeouts, Überlast-Antworten (HTTP 429 Too Many Requests, 503 Service Unavailable) oder kurzzeitige Verbindungsabbrüche. So wird aus einem einzelnen Ausfall ein gelungener Aufruf, ohne dass der Nutzer etwas merkt.
Exponential Backoff und Jitter
Statt sofort und hektisch zu wiederholen, wartet ein Retry mit exponentiellem Backoff: Die Wartezeit verdoppelt sich je Versuch (etwa 1 s, 2 s, 4 s, 8 s). Zusätzlich streut ein Jitter (zufällige Abweichung) die Wiederholungen, damit nicht alle Clients gleichzeitig erneut zuschlagen (Thundering-Herd-Effekt). AWS empfiehlt in seiner Prescriptive Guidance für Cloud-Designs genau dieses Muster mit maximaler Versuchszahl und Obergrenze für die Wartezeit.
Grenzen und Absicherung
Wichtige Regeln: Nicht jeder Fehler ist wiederholbar — nur transiente Fehler (Netzwerk, 429, 503) sollten wiederholt werden, keine logischen Fehler wie 400 oder 401. Mutationen (POST, PUT, DELETE) dürfen nur wiederholt werden, wenn die Operation idempotent ist, sonst drohen Doppelbuchungen. Ein Retry-Budget begrenzt die Gesamtzahl der Versuche, der HTTP-Header Retry-After nennt dem Client eine konkrete Wartezeit. Endgültig gescheiterte Nachrichten wandern in eine Dead Letter Queue.
Die Retry-Logik arbeitet eng mit dem Circuit Breaker zusammen: Gegen einen offenen Breaker darf nicht endlos retryt werden. Backpressure verhindert dagegen, dass ein schneller Absender einen langsamen Empfänger überflutet.
Verwandte Grundlagen: API Gateway, Rate Limiting, Mikroservice, Verteilte Systeme, Transaktion, Resilienz.