Una API de terceros de la que dependes empieza a dar timeouts intermitentes. ¿Qué haces?

Conténlo primero: pon un timeout agresivo para que su latencia no se convierta en la tuya, reintenta con backoff exponencial y jitter solo en llamadas idempotentes, y pon un circuit breaker delante para dejar de machacar algo que ya está caído. Después decide cómo es el comportamiento degradado: encolar el trabajo para después, servir un valor cacheado, o fallar en esa funcionalidad mientras el resto del producto sigue funcionando.

Lo primero que compruebo es si siquiera tenemos un timeout, porque el valor por defecto en muchos clientes HTTP es efectivamente infinito, y así es como un proveedor lento te llena el pool de workers y tumba endpoints que no tienen nada que ver con él. Así que un timeout agresivo, más ajustado que mi propio SLA. Después reintentos, pero solo en llamadas seguras de repetir, con backoff exponencial y jitter, porque los reintentos sincronizados de todas las instancias convierten su bajón en una caída total. Delante va un circuit breaker, así que tras una racha de fallos dejamos de llamar un rato y fallamos rápido en vez de encolar. Después la pregunta de producto, que es la interesante: ¿qué debería ver el usuario? Para una llamada de validación de direcciones dejaría pasar el pedido y lo marcaría para revisión. Para una autorización de pago no puedo fingirla, así que encolo el intento y se lo digo al usuario con honestidad. Y estaría en su canal de soporte con ids de petición todo el rato.