Anatomie eines Retry-Sturms

Übungskontext

Dies ist eine hypothetische Störungsanalyse, kein Bericht über einen Produktionsvorfall. Sie untersucht, wie Wiederholungen einen kleinen Ausfall zu einer größeren Störung ausweiten können.

Was passiert ist

Ein nachgelagerter Dienst wurde langsamer. Aufrufer erreichten ihr Timeout und wiederholten sofort. Jede Schicht hatte ihre eigene Retry-Strategie und vervielfachte die Last genau dann, als die Abhängigkeit am wenigsten freie Kapazität hatte.

Beispielhafter Ablauf

Relative Zeit	Beobachtung
T+0	Die Latenz der Abhängigkeit steigt.
T+2 Min.	Sofortige Retries erhöhen die Parallelität.
T+5 Min.	Worker-Pools sind ausgelastet; Warteschlangen wachsen.
T+8 Min.	Das Team reduziert Retries und verwirft optionale Arbeit.
T+15 Min.	Warteschlangen leeren sich; erfolgreiche Anfragen nehmen zu.

Begünstigende Bedingungen

Es gab Timeouts pro Anfrage, aber keine durchgehende Deadline. Retries hatten kein gemeinsames Budget. Identische Wiederholungsintervalle synchronisierten die Aufrufer.

Verbesserungen

1. Einer Schicht die Verantwortung für Retries geben und Versuche innerhalb einer durchgehenden Deadline begrenzen.
2. Exponentielles Backoff mit Jitter verwenden und Retry-Hinweise des Servers beachten.
3. Parallelität und Warteschlangenlänge begrenzen; überschüssige Arbeit früh ablehnen.
4. Idempotenzschlüssel für wiederholte Schreiboperationen verlangen.
5. Langsame Abhängigkeiten unter Last testen und vorhersehbare Degradierung bestätigen.

Verifikation

Die Fehlersimulation mit der neuen Strategie wiederholen. Versuche mit ursprünglichen Anfragen, Warteschlangenalter und abgeschlossener Arbeit vergleichen. Eine wirksame Maßnahme begrenzt die Verstärkung und erhält nutzbaren Durchsatz.