Dein Service ruft eine Drittanbieter-API auf, die gelegentlich langsam wird. Wie konfigurierst du den Client, damit dich das nicht mit runterzieht?

Setz explizite Connect- und Read-Timeouts auf dem Client, denn mehrere Java-HTTP-Clients warten per Default unendlich, und ergänze ein Gesamt-Timeout für den Request. Begrenz den Connection Pool für diesen Host, wiederhol nur idempotente Calls mit Backoff und Jitter, und setz einen Circuit Breaker davor, damit anhaltende Fehler schnell scheitern. Entscheid den Fallback vorher: ein gecachter Wert, eine degradierte Antwort oder ein klarer Fehler statt eines hängenden Requests.

Ich gehe von der Annahme aus, dass die Defaults falsch sind, denn mehrere Clients warten bei einem Read fröhlich ewig, und genau so wird aus einer langsamen Abhängigkeit ein Zustand, in dem jeder Thread meines Service geparkt ist. Also kurzes Connect-Timeout, ein Read-Timeout auf Basis ihrer tatsächlichen Latenzverteilung statt einer runden Zahl, und obendrauf ein Gesamt-Timeout für den Request, weil sich Retries und Redirects stapeln können. Dann Isolation: diese Abhängigkeit bekommt einen eigenen Connection Pool mit Maximum, damit sie bei Degradierung nicht die gesamte Kapazität frisst, die andere Calls brauchen. Retries nur bei idempotenten Operationen, gedeckelt auf zwei Versuche mit exponentiellem Backoff und Jitter, und ein Circuit Breaker davor, damit ich ab einer Fehlerrate über der Schwelle sofort scheitere und eine Abkühlphase abwarte, statt Requests auf etwas zu stapeln, das ohnehin schon kämpft. Das letzte Stück ist, was der Nutzer bekommt, und das wird vorher entschieden. Bei einer Integration für Versandkosten haben wir gecachte Tarife mit einer Veraltungsmarkierung ausgeliefert, statt den Checkout scheitern zu lassen, und damit wurde aus einem Ausfall beim Anbieter ein kleines Genauigkeitsproblem statt verlorener Bestellungen. Ich teste das mit einem Proxy, der Verzögerungen einbaut.