¿Cómo haces una llamada a una dependencia que puede estar lenta o caída?

Pon un timeout explícito en cada llamada, más corto que el plazo del propio llamante, y nunca confíes en el valor por defecto de la librería cliente. Reintenta solo operaciones idempotentes, con backoff exponencial más jitter y un número pequeño y acotado de intentos. Añade un circuit breaker para que los fallos repetidos fallen rápido en vez de encolarse, y define qué significa degradado: un valor cacheado, una respuesta parcial o un error claro en vez de una petición colgada.

Lo primero es un timeout en cada llamada saliente, elegido a partir de la distribución de latencia y no al azar, y siempre más corto que el plazo que me han dado, para fallar antes de que mi llamante se rinda. Propago ese plazo restante hacia abajo, porque si no se sigue trabajando en una petición que ya no espera nadie. Los reintentos solo aplican a llamadas idempotentes, y aun así con backoff exponencial y jitter, limitados a dos o tres intentos. El motivo del límite es la amplificación: si cada capa reintenta tres veces, un hipo abajo se convierte en un orden de magnitud más de carga, que es como una dependencia lenta acaba en una caída completa. Por eso también me gusta un presupuesto de reintentos, donde los reintentos se limitan a un pequeño porcentaje del total de peticiones. Encima va un circuit breaker para que, en cuanto los fallos crucen un umbral, falle de inmediato durante un enfriamiento y sondee de vez en cuando, lo que evita apilar peticiones sobre algo que ya sufre. Y decido de antemano qué significa degradado; en un servicio de precios servíamos el último precio cacheado con una marca de antigüedad en vez de tumbar el checkout.