Tu servicio llama a una API de terceros que de vez en cuando se pone lenta. ¿Cómo configuras el cliente para que eso no te tumbe?

Pon timeouts explícitos de conexión y de lectura en el cliente, porque varios clientes HTTP de Java esperan indefinidamente por defecto, y añade un timeout global de petición. Acota el pool de conexiones para ese host, reintenta solo llamadas idempotentes con backoff y jitter, y añade un circuit breaker para que los fallos sostenidos fallen rápido. Decide el fallback de antemano: un valor cacheado, una respuesta degradada, o un error claro en vez de una petición colgada.

Parto del supuesto de que los valores por defecto están mal, porque varios clientes esperan felizmente para siempre en una lectura, y así es exactamente como una dependencia lenta se convierte en que todos los hilos de mi servicio queden parados. Así que timeout de conexión corto, timeout de lectura basado en su distribución real de latencia y no en un número redondo, y encima un timeout global de petición, ya que los reintentos y las redirecciones se acumulan. Luego aislamiento: esa dependencia recibe su propio pool de conexiones con un máximo, así que cuando se degrada no puede consumir toda la capacidad que otras llamadas necesitan. Reintentos solo en operaciones idempotentes, con un tope de dos intentos, backoff exponencial y jitter, y un circuit breaker delante para que en cuanto la tasa de error cruce un umbral falle de inmediato durante un enfriamiento en vez de amontonar peticiones sobre algo que ya está sufriendo. La última pieza es qué recibe el usuario, decidido de antemano. En una integración de tarifas de envío servíamos tarifas cacheadas con una marca de antigüedad en lugar de tumbar el checkout, y eso convirtió una caída del proveedor en un problema menor de exactitud en vez de en pedidos perdidos. Lo pruebo con un proxy que inyecta retrasos.