Timeouts, Retries und Idempotenz

In verteilten Systemen ist das Netzwerk nie ganz zuverlässig. Anfragen gehen verloren, Antworten kommen verspätet, Dienste sind kurz überlastet. Die Frage ist nicht, ob solche Fehler auftreten, sondern wie das System damit umgeht. Drei Werkzeuge sind dafür zentral: Zeitlimits, die verhindern, dass man ewig wartet; Wiederholungen, die vorübergehende Fehler überbrücken; und Idempotenz, die dafür sorgt, dass Wiederholungen keinen Schaden anrichten. Falsch eingesetzt, verschlimmern Wiederholungen allerdings Ausfälle, statt sie zu beheben. Diese Lektion zeigt, wie man es richtig macht.

1. Zeitlimits

Jeder Aufruf über das Netzwerk – an eine Datenbank, einen externen Dienst, ein Sprachmodell – braucht ein Zeitlimit. Ohne Zeitlimit kann eine hängende Verbindung eine Anfrage beliebig lange blockieren. Bei vielen gleichzeitigen Anfragen sind dann schnell alle Threads oder Verbindungen belegt, und das System steht still, obwohl nur ein einzelner Dienst langsam ist. Viele Bibliotheken haben standardmäßig kein oder ein sehr langes Zeitlimit, das man bewusst setzen muss.

Wie lang sollte ein Zeitlimit sein? Es sollte sich an der gemessenen normalen Antwortzeit orientieren, typischerweise an einem hohen Perzentil wie dem 99. Perzentil plus etwas Reserve. Antwortet ein Dienst normalerweise in 200 Millisekunden und in 99 Prozent der Fälle in unter 800 Millisekunden, ist ein Zeitlimit von einer Sekunde sinnvoll, nicht eines von dreißig Sekunden. Wichtig ist außerdem das Zeitbudget der gesamten Anfrage: Wenn der Nutzer nach zwei Sekunden eine Antwort erwartet, dürfen die inneren Aufrufe zusammen nicht länger dauern. Das Budget wird von außen nach innen weitergegeben, sodass tiefere Aufrufe wissen, wie viel Zeit ihnen noch bleibt.

2. Wiederholungen richtig gestalten

Viele Fehler sind vorübergehend: eine kurz überlastete Datenbank, ein abgebrochenes Netzwerkpaket, ein Neustart eines Dienstes. Eine Wiederholung nach kurzer Zeit ist dann oft erfolgreich. Aber Wiederholungen haben eine Kehrseite. Wenn ein Dienst überlastet ist und alle Clients sofort wiederholen, verdoppelt oder verdreifacht sich die Last – genau im ungünstigsten Moment. Deshalb gelten drei Regeln: Die Wartezeit zwischen Versuchen wächst exponentiell, etwa eine, zwei, vier, acht Sekunden. Sie enthält einen Zufallsanteil, den Jitter, damit nicht alle Clients gleichzeitig wiederholen. Und die Zahl der Versuche ist begrenzt. Sehen Sie selbst:

Nicht jeder Fehler sollte wiederholt werden. Ein Fehler wie „Anfrage ungültig“ oder „nicht berechtigt“ wird beim zweiten Versuch nicht besser. Wiederholt werden nur Fehler, die vorübergehend sein können: Zeitüberschreitungen, Verbindungsabbrüche, Überlastmeldungen wie HTTP 503 oder 429. Bei 429 teilt der Server oft über den Header Retry-After mit, wann ein neuer Versuch sinnvoll ist – daran sollte man sich halten. Außerdem sollten Wiederholungen nur auf einer Ebene stattfinden. Wenn der Browser dreimal wiederholt, das Backend dreimal und die Datenbankbibliothek dreimal, werden aus einem Fehler 27 Anfragen.

3. Idempotenz

Wiederholungen sind nur sicher, wenn die Operation idempotent ist, also mehrfach ausgeführt dasselbe Ergebnis hat wie einmal. Lesende Anfragen sind von Natur aus idempotent, ebenso das Setzen eines Werts. Kritisch sind Operationen wie „Zahlung ausführen“ oder „Bestellung anlegen“. Hier ist die Unsicherheit besonders groß: Wenn die Verbindung abbricht, weiß der Client nicht, ob die Zahlung durchgeführt wurde oder nicht. Wiederholt er, droht eine doppelte Abbuchung. Probieren Sie es aus:

Die Lösung ist ein Idempotenzschlüssel: Der Client erzeugt für jeden Vorgang eine eindeutige Kennung und sendet sie mit jeder Anfrage, auch bei Wiederholungen. Der Server speichert zu jedem Schlüssel das Ergebnis. Kommt eine Anfrage mit bekanntem Schlüssel, führt er die Operation nicht erneut aus, sondern liefert das gespeicherte Ergebnis. Zahlungsdienste wie Stripe setzen dieses Muster konsequent ein. Technisch braucht es dafür eine Tabelle mit eindeutigem Schlüssel und eine Transaktion, die das Speichern des Schlüssels und die eigentliche Operation zusammenfasst.

4. Circuit Breaker

Wenn ein Dienst dauerhaft ausgefallen ist, sind selbst gut gestaltete Wiederholungen sinnlos. Jede Anfrage wartet bis zum Zeitlimit, belegt Ressourcen und scheitert dann doch. Ein Circuit Breaker, zu Deutsch Schutzschalter, erkennt das. Wenn ein bestimmter Anteil der Aufrufe fehlschlägt, öffnet er sich und lässt Aufrufe für eine Weile sofort scheitern, ohne den Dienst zu kontaktieren. Nach einer Wartezeit lässt er einzelne Testanfragen durch; sind sie erfolgreich, schließt er sich wieder. So schützt er den eigenen Dienst vor Blockade und gibt dem ausgefallenen Dienst Zeit zur Erholung.

Zum Circuit Breaker gehört ein Fallback: Was zeigt die Anwendung, wenn der Dienst nicht erreichbar ist? Eine Empfehlungsleiste kann ausgeblendet werden, eine Wetteranzeige kann den letzten bekannten Wert zeigen, ein KI-Assistent kann höflich mitteilen, dass er gerade nicht verfügbar ist. Entscheidend ist, dass der Ausfall eines Nebendienstes nicht die ganze Anwendung mitreißt. Man nennt das graceful degradation, eine kontrollierte Verschlechterung statt eines Totalausfalls.

5. Kaskadenausfälle

Zeitlimits, gute Wiederholungen, Idempotenz und Circuit Breaker wirken zusammen gegen ein gefürchtetes Muster: den Kaskadenausfall. Er beginnt oft harmlos. Ein Dienst wird langsamer, Aufrufer warten länger, ihre Verbindungen füllen sich, sie werden selbst langsam, ihre Aufrufer wiederholen, die Last steigt weiter, und am Ende ist das ganze System ausgefallen, obwohl die ursprüngliche Ursache klein war. Viele große Störungen bekannter Dienste folgen genau diesem Muster. Wer beim Entwurf jeden externen Aufruf mit diesen vier Werkzeugen absichert, verhindert, dass ein einzelnes Problem sich ausbreitet.

6. Ein Beispiel

Eine Arztpraxis-App bietet Terminbuchung an und nutzt dafür die Schnittstelle einer Praxissoftware, die gelegentlich langsam ist. Der Entwurf legt fest: Aufrufe an die Praxissoftware haben ein Zeitlimit von drei Sekunden. Bei Zeitüberschreitungen und 503-Fehlern wird bis zu zweimal mit Backoff und Jitter wiederholt. Jede Buchung trägt einen Idempotenzschlüssel, damit Wiederholungen keine Doppelbuchungen erzeugen. Ein Circuit Breaker öffnet bei mehr als der Hälfte fehlgeschlagener Aufrufe in einer Minute; die App zeigt dann einen Hinweis und bietet an, einen Rückruf anzufordern, der über eine Warteschlange später verarbeitet wird. So bleibt die App auch bei Problemen der Praxissoftware nutzbar, und kein Patient erhält zwei Termine.

7. Merkliste für externe Aufrufe

Für jeden Aufruf eines anderen Dienstes lohnt sich eine kurze Prüfung: Ist ein Zeitlimit gesetzt, das zur gemessenen Antwortzeit passt? Wird nur bei vorübergehenden Fehlern wiederholt, mit Backoff, Jitter und einer Obergrenze? Ist die Operation idempotent oder durch einen Schlüssel abgesichert? Gibt es einen Fallback, falls der Dienst länger ausfällt? Und werden Fehler, Wiederholungen und Zeitüberschreitungen gemessen, sodass Probleme sichtbar werden, bevor Nutzer sich beschweren? Wer diese Fragen für jede Abhängigkeit beantwortet, hat die häufigsten Ursachen großer Störungen bereits im Entwurf entschärft.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.