Tiempos de espera y dependencias caídas

Mientras una petición espera a un servicio externo, el proceso que la atiende queda ocupado. Si no se declara un tiempo de espera, se usa el del cliente HTTP: en el de Laravel son 30 segundos para toda la petición y 10 para conectar. Cuando una dependencia se vuelve lenta, cada visitante que la toca retiene un proceso hasta ese límite; con suficientes visitantes no queda ninguno libre y la aplicación entera deja de responder, incluidas rutas que nunca usan esa dependencia. Es una falla en cascada, y la aprovecha igual un pico de tráfico legítimo que alguien que la provoca a propósito.

Los reintentos agravan el problema si no se piensan: multiplican la espera y la carga sobre un servicio que ya está mal. Se limitan, se espacian cada vez más y solo se aplican a operaciones que se pueden repetir sin efectos dobles.

Abre el laboratorio y lee servicios.php. Cada bloque declara a dónde se conecta la tienda y, en la mayoría, cuánto espera. Compara los cinco bloques y cruza el resultado con tablero-incidente.txt: el 20 de noviembre los 64 procesos web quedaron ocupados y el catálogo devolvió cientos de errores, con un solo proveedor en problemas.

Ahora lee ClienteTransportadora.php. En el cliente HTTP de Laravel, el primer número de retry es el total de intentos, y el segundo, los milisegundos de pausa entre uno y otro. Cada intento puede esperar hasta el límite que tenga la llamada, y esta llamada no declara ninguno. Calcula cuánto puede quedar ocupado un proceso web por una sola cotización cuando la transportadora contesta justo al borde del límite en todos los intentos.

El cliente HTTP de Laravel no lanza una excepción cuando el servidor responde con un código 4xx o 5xx: devuelve la respuesta y es el código quien debe mirar si fue correcta. Lee ClienteAntifraude.php y CheckoutController.php. El controlador sí maneja bien las excepciones, que aquí son los tiempos de espera agotados: manda el pedido a revisión manual. Pero una respuesta 503 no es una excepción, y el cliente solo compara la decisión con un valor.

El registro tiene un segundo síntoma del mismo error: el pedido SV-40507 recibió la decisión revisar, que el proveedor introdujo en su versión 2, y también terminó aprobado. Las dos fallas vienen de escribir la condición al revés: el código enumera lo que bloquea y aprueba todo lo demás, incluido lo que no entiende. Un control de seguridad hace lo contrario: aprueba solo ante una respuesta correcta y explícita, y cualquier otra cosa la trata como duda.