Retry-Logik

Programme fragen ständig bei anderen Computern nach Daten. Eine Wetter-App fragt einen fremden Rechner nach der Temperatur, eine Bank-App nach dem Kontostand. Manchmal kommt keine Antwort zurück: die Leitung stockt, der andere Rechner ist gerade überlastet. Retry-Logik ist die fest eingebaute Regel, es in so einem Fall automatisch noch einmal zu versuchen, ohne dass ein Mensch etwas tut. Sie beantwortet drei Fragen: Wie oft wird wiederholt? Wie lange wird zwischen den Versuchen gewartet? Und wann gibt das Programm endgültig auf und meldet einen Fehler?

Warum ein zweiter Versuch oft schon reicht

Viele Störungen im Netz sind vorübergehend. Ein Server ist für eine halbe Sekunde ausgelastet, ein Datenpaket geht unterwegs verloren, eine Verbindung wird neu aufgebaut. Solche Fehler nennt man transient, also flüchtig. Wer nur eine Sekunde wartet und es erneut probiert, bekommt in vielen Fällen eine saubere Antwort.

Ohne Retry-Logik würde jede dieser Mini-Störungen bis zum Nutzer durchschlagen. Die App zeigt eine Fehlermeldung, obwohl gar nichts kaputt ist. Bei großen Diensten summiert sich das: Wenn eine einzelne Anfrage nur zu 99,9 Prozent gelingt, scheitern bei einer Million Anfragen pro Tag trotzdem tausend. Ein automatischer zweiter Versuch drückt diese Zahl auf einen Bruchteil.

Besonders wichtig ist das bei KI-Diensten. Ein Sprachmodell antwortet über eine Schnittstelle im Internet, also über eine Adresse, an die ein Programm seine Anfrage schickt. Diese Schnittstellen sind oft stark ausgelastet und weisen Anfragen mit der Meldung « zu viele Anfragen » zurück. Programme, die solche KI-Dienste nutzen, brauchen deshalb fast immer eine Retry-Logik, sonst brechen sie im Alltagsbetrieb ständig ab.

Exponentielles Backoff und der Zufallszuschlag

Der naive Ansatz wäre, sofort und immer wieder nachzufragen. Das macht die Lage aber schlimmer. Ist ein Server überlastet, prasseln jetzt noch mehr Anfragen auf ihn ein. Deshalb nutzt man exponentielles Backoff: Die Wartezeit verdoppelt sich nach jedem Fehlversuch. Also erst eine Sekunde warten, dann zwei, dann vier, dann acht. Nach etwa fünf Versuchen bricht das Programm ab und meldet den Fehler ehrlich weiter.

Dazu kommt ein Zufallszuschlag, im Fachjargon Jitter. Stell dir tausend Handys vor, die zur gleichen Sekunde eine Störung erleben. Ohne Zufall würden alle exakt eine Sekunde später gleichzeitig erneut anfragen und den Server ein zweites Mal umwerfen. Mit einem zufälligen Zuschlag von wenigen hundert Millisekunden verteilen sich die Versuche sauber über die Zeit.

Ein häufiger Irrtum ist, dass man alles wiederholen darf. Das stimmt nicht. Wiederholen lohnt sich nur bei flüchtigen Fehlern. Lautet die Antwort dagegen « Passwort falsch » oder « diese Adresse gibt es nicht », ändert auch der zehnte Versuch nichts. Gefährlich wird es bei Aktionen, die etwas verändern, etwa einer Überweisung. Wenn die erste Anfrage in Wahrheit ankam und nur die Bestätigung verloren ging, bucht der zweite Versuch doppelt ab. Dagegen hilft eine mitgeschickte Kennnummer, an der der Server erkennt, dass es sich um denselben Auftrag handelt.

Vom Ladebalken bis zur Störungsmeldung

Im Alltag merkt man Retry-Logik meist nur daran, dass man sie nicht merkt. Der Ladebalken dreht sich eine Sekunde länger als sonst, dann ist das Video da. Im Hintergrund lief womöglich schon der dritte Versuch. Auch Streaming-Dienste, Messenger und Online-Spiele arbeiten permanent mit solchen Wiederholungen.

In Tech-News taucht der Begriff meist nach großen Ausfällen auf. In den Analysen nach einer Störung liest man dann, dass eine schlecht eingestellte Retry-Logik den Ausfall verlängert habe. Der Mechanismus heißt Retry-Sturm: Ein Dienst wackelt, Millionen Clients probieren es sofort erneut, und die Flut an Wiederholungen hält den Dienst unten, obwohl das ursprüngliche Problem längst behoben ist.

Wer selbst programmiert, muss Retry-Logik heute selten von Hand schreiben. Fertige Programmbibliotheken und die offiziellen Zugangspakete großer Anbieter bringen sie mit. Man stellt nur noch ein, wie viele Versuche erlaubt sind und wie lange gewartet wird. Verwandt, aber nicht dasselbe ist der Circuit Breaker: Er stoppt Anfragen an einen erkennbar toten Dienst komplett, statt sie weiter zu wiederholen.