Glossar · Tech & Architecture
Retry-Strategie, bei der die Wartezeit zwischen Versuchen exponentiell steigt — typischerweise mit zufälligem Jitter, um Thundering-Herd-Effekte zu vermeiden.
Definition
Statt nach einem Fehler sofort oder in festem Intervall neu zu versuchen, wartet exponential Backoff progressiv länger: 1s, 2s, 4s, 8s, 16s, 32s usw. Das gibt dem ausgefallenen System Zeit, sich zu erholen, und reduziert die Last während eines Outages.
Wichtiger Zusatz: Jitter — eine zufällige Komponente in der Wartezeit. Ohne Jitter starten alle Clients nach einem gemeinsamen Outage synchron ihre Retries, produzieren einen Lastpeak und triggern den nächsten Outage (Thundering Herd). 'Full Jitter' (Wartezeit zwischen 0 und Backoff-Maximum) hat sich in der Praxis als robusteste Wahl etabliert.
Cap: meist ein Maximalwert (z. B. 5 Min), damit Retries nicht stundenlang warten. Kombiniert mit Max-Attempts (typisch 5-7), bevor der Job in die DLQ wandert.
So nutzen wir das bei adsbird
In allen Worker-Implementierungen nutzen wir Full-Jitter-Backoff mit Cap bei 5 Min und Max 6 Attempts — das ist robust gegen Hubspot- und Salesforce-Outages (die regelmäßig vorkommen) und vermeidet Thundering-Herd nach deren Recovery.
Verwandte Begriffe
Exponential Backoff in deinem Projekt?
Wenn du Exponential Backoff in einem konkreten Workflow brauchst — wir haben das wahrscheinlich schon gebaut.