Por qué tu integración se rompe siempre a fin de mes
Es fácil subestimar el trabajo de integración porque el camino feliz es de verdad sencillo: llamar al endpoint, mapear los campos, guardar el resultado. El problema es que el camino feliz no es lo que se ejecuta el último día hábil del mes.
Lento no es lo mismo que caído
Un sistema caído falla rápido y de forma evidente. Uno que solo va lento mantiene tu conexión abierta, agota tu pool y se lleva tu servicio por delante. Si tu tiempo de espera es mayor que la paciencia de quien te llama, una ralentización aguas arriba se convierte en tu caída.
Pon tiempos de espera agresivos y un cortacircuitos. Fallar rápido y con claridad casi siempre es mejor que esperar con esperanza.
Los reintentos necesitan idempotencia para ser seguros
Reintentar una petición que expiró solo tiene sentido si el otro lado puede reconocerla como repetida. Si no, justo lo que añadiste para dar fiabilidad empieza a crear pedidos, facturas y pagos duplicados, y precisamente bajo la carga que provocó el timeout.
- Envía una clave de idempotencia estable con todo lo que cree o modifique estado.
- Aplica backoff exponencial con jitter, para que los reintentos no lleguen como una ola sincronizada.
- Limita los intentos y manda el resto a una cola de mensajes fallidos que una persona pueda revisar.
Concilia, no supongas
Los dos lados deberían poder responder a «¿cuántos registros viste hoy y cuáles eran sus totales?». Una conciliación diaria que compare esas respuestas convierte una divergencia silenciosa en una alerta el mismo día en que empieza.
Prueba contra el día malo
Apunta la integración a un stub que vaya lento, devuelva respuestas parciales y falle una llamada de cada veinte. Casi todo lo que te va a doler en producción aparece en la primera hora, y encontrarlo un martes por la tarde sale mucho más barato que a fin de mes.
