Was ist Exponential Backoff und Random Jitter?

Bei der Entwicklung verteilter Systeme sind Fehler keine Ausnahme, sondern die Norm. Das Netzwerk kann hängen bleiben, der Dienst kann vorübergehend ausfallen, die Datenbank kann für eine Sekunde nicht reagieren. Und in diesem Moment stellt sich eine einfache, aber gefährliche Frage: Wie genau soll die Anfrage wiederholt werden? Wenn man es auf die gleiche Weise macht, wird das System sich leicht selbst zerstören.

Genau hier kommen exponentielle Verzögerung (exponential backoff) und zufälliger Jitter (random jitter) ins Spiel.

Exponential Backoff ist eine Strategie für Wiederholungsversuche, bei der jeder nachfolgende Retry (Wiederholungsversuch) mit einer zunehmend größeren Verzögerung erfolgt. Die Idee ist sehr einfach: Wenn etwas kaputt ist, sollte man nicht sofort wieder an die gleiche Tür klopfen. Der erste Versuch kann fast sofort sein, der zweite nach einer Sekunde, der dritte nach zwei, dann vier, acht und so weiter. Die Verzögerung wächst exponentiell.

Das gibt dem System Zeit, "durchzuatmen". Wenn der Dienst vorübergehend überlastet ist oder aufgrund von Spitzenlasten ausfällt, verringert der exponentielle Backoff den Druck, anstatt ihn zu erhöhen. Ohne diese Strategie beginnen die Kunden, massenhaft gleichzeitig Retry zu machen, und selbst ein gesunder Dienst kann einem solchen Ansturm nicht standhalten.

Aber hier gibt es einen heimtückischen Punkt. Stellen Sie sich tausend Kunden vor, die gleichzeitig einen Fehler erhalten und die gleiche Backoff-Formel verwenden. Sie alle werden eine Sekunde warten, dann zwei, dann vier - und schlagen wieder gleichzeitig auf den Server ein. Es entsteht eine synchronisierte Menge, die in Wellen kommt. Das ist ein bekanntes Problem - der Effekt des "thundering herd".

Deshalb wird zum exponentiellen Backoff fast immer zufälliger Jitter (random jitter) hinzugefügt. Jitter ist eine kleine zufällige Abweichung in der Verzögerung. Anstatt genau 4 Sekunden zu warten, kann der Kunde 3,2 warten, ein anderer 4,7, jemand anders 2,9. Alle diese exponentiellen Verzögerungen bleiben bestehen, aber die Anfragen kommen nicht mehr gleichzeitig.

Mit Jitter beginnt das System, "lebendiger" und stabiler zu agieren. Die Last wird über die Zeit verteilt, es ist für den Dienst einfacher, sich zu erholen, und die Wahrscheinlichkeit eines erneuten Ausfalls aufgrund massenhafter Retries sinkt drastisch. Dies ist besonders wichtig für APIs, Warteschlangen, Job-Worker und alle Integrationen mit externen Diensten.

Zusammenfassend beantwortet der exponentielle Backoff die Frage "Wann soll ich wiederholen?", während der Jitter die Frage "Wie mache ich das asynchron zu allen anderen?" beantwortet. Zusammen bilden sie die grundlegende Architektur für zuverlässige Systeme. Wenn Sie einen Retry ohne Backoff haben - ist das ein rotes Signal. Wenn es Backoff ohne Jitter gibt - ein gelbes. Und wenn beides vorhanden ist, hat das System deutlich bessere Chancen, echte und nicht labortechnische Ausfälle zu überstehen.