Eine Drittanbieter-API, von der du abhängst, läuft sporadisch in Timeouts. Was machst du?

Grenz es zuerst ein: Setz ein aggressives Timeout, damit ihre Latenz nicht zu deiner wird, wiederhol mit exponentiellem Backoff und Jitter nur bei idempotenten Aufrufen, und setz einen Circuit Breaker davor, damit du nicht weiter auf etwas einhämmerst, das ohnehin schon unten ist. Dann entscheide, wie degradiertes Verhalten aussieht: Arbeit für später einreihen, einen gecachten Wert ausliefern, oder dieses eine Feature scheitern lassen, während der Rest des Produkts weiterläuft.

Als Erstes prüfe ich, ob wir überhaupt ein Timeout haben, denn der Default in vielen HTTP-Clients ist praktisch unendlich, und genau so füllt ein langsamer Anbieter deinen Worker Pool und legt Endpoints lahm, die nichts mit ihm zu tun haben. Also ein aggressives Timeout, enger als mein eigenes SLA. Dann Retries, aber nur bei Aufrufen, die sicher wiederholbar sind, mit exponentiellem Backoff und Jitter, denn synchronisierte Retries von jeder Instanz machen aus ihrem Brownout einen kompletten Ausfall. Davor kommt ein Circuit Breaker, sodass wir nach einer Serie von Fehlern eine Weile nicht mehr aufrufen und schnell scheitern, statt uns aufzustauen. Dann die Produktfrage, die die interessante ist: Was soll der User sehen? Bei einem Aufruf zur Adressvalidierung würde ich die Bestellung durchlassen und sie zur Prüfung markieren. Bei einer Zahlungsautorisierung kann ich das nicht faken, ich reihe den Versuch also ein und sage es dem User ehrlich. Und ich wäre die ganze Zeit mit Request-ids in ihrem Support-Kanal.