Wie rufst du einen Service auf, der langsam oder ausgefallen sein könnte?

Setz auf jedem Aufruf ein explizites Timeout, kürzer als deine eigene Deadline, und verlass dich nie auf den Default der Client-Library. Wiederhol nur idempotente Operationen, mit exponentiellem Backoff plus Jitter und einer kleinen, begrenzten Anzahl Versuche. Bau einen Circuit Breaker ein, damit wiederholte Fehler schnell scheitern statt sich aufzustauen, und definier, wie degradiert aussieht: ein gecachter Wert, eine Teilantwort oder ein klarer Fehler statt eines hängenden Requests.

Das Erste ist ein Timeout auf jedem ausgehenden Aufruf, gewählt aus der Latenzverteilung statt zufällig gegriffen, und immer kürzer als die Deadline, die ich bekommen habe, damit ich scheitere, bevor mein Aufrufer aufgibt. Diese Restdeadline gebe ich nach unten weiter, sonst läuft Arbeit weiter für einen Request, auf den niemand mehr wartet. Retries gelten nur für idempotente Aufrufe, und selbst dann mit exponentiellem Backoff und Jitter, gedeckelt auf zwei oder drei Versuche. Der Grund für den Deckel ist Amplifikation: wenn jede Schicht dreimal wiederholt, wird aus einem Aussetzer ganz unten eine Größenordnung mehr Last, und genau so wird aus einer langsamen Abhängigkeit ein kompletter Ausfall. Deshalb mag ich auch ein Retry-Budget, bei dem Retries auf einen kleinen Prozentsatz aller Requests begrenzt sind. Darüber sitzt ein Circuit Breaker, sodass ich nach Überschreiten einer Fehlerschwelle sofort scheitere, eine Abkühlphase abwarte und gelegentlich prüfe, was verhindert, dass ich Requests auf etwas stapele, das schon kämpft. Und ich lege vorher fest, was degradiert heißt; bei einem Pricing-Service haben wir den letzten gecachten Preis mit einem Staleness-Flag ausgeliefert, statt den Checkout scheitern zu lassen.