Warum machen naive Retries einen Ausfall schlimmer, und wie würdest du eine sichere Retry-Policy entwerfen?

Naive Retries vervielfachen Last genau dann, wenn ein Service ohnehin kämpft, und synchronisierte Clients wiederholen im Gleichschritt in Wellen. Nimm Exponential Backoff mit Full Jitter, deckel die Gesamtzahl der Versuche und wiederhol nur idempotente Operationen bei wiederholbaren Fehlern. Ergänz ein clientseitiges Retry-Budget, damit Retries ein kleiner Anteil am Traffic bleiben, plus einen Circuit Breaker, der Aufrufe ganz stoppt, wenn die Fehlerrate hochschießt. Wiederhol nie unabhängig auf jeder Ebene des Stacks.

Das Problem ist, dass Retries zusätzliche Last zum denkbar schlechtesten Zeitpunkt sind. Scheitert ein Service zu 50% und jeder Client wiederholt dreimal, hast du den Traffic auf etwas verdreifacht, das schon über der Kapazität liegt, und es bekommt nie eine Chance, sich zu erholen. Reines Exponential Backoff reicht auch nicht, denn alle deine Clients sind im selben Moment gescheitert, also wachen sie im selben Moment wieder auf. Full Jitter behebt das, die Wartezeit ist dann ein Zufallswert zwischen null und der aktuellen Backoff-Obergrenze. Darüber hinaus würde ich nur idempotente Aufrufe wiederholen, nur bei 503, 429 und Fehlern auf Verbindungsebene, nie bei einem 400, und ich würde ein Retry-Budget durchsetzen, das Retries auf etwa 10% aller Requests deckelt. Was uns erwischt hat, war das Schichten. Das SDK hat dreimal wiederholt, das Mesh zweimal und der Job Runner noch einmal, das sind achtzehn Versuche für einen logischen Aufruf.