Un caso posible: el ERP recibe el pedido 4512, pero la respuesta no llega al ecommerce. ¿Se creó el pedido o hay que enviarlo otra vez? Si se reintenta sin comprobarlo, puede quedar duplicado. Si se da por entregado, puede no existir en el ERP. Esta duda aparece incluso cuando ambos sistemas funcionan la mayor parte del tiempo.
Para resolverla, la integración necesita distinguir tipos de error, reintentar de forma segura y dejar un estado que alguien pueda consultar.
Distinguir errores transitorios de errores permanentes
El primer paso es clasificar los errores, porque cada tipo requiere una respuesta distinta:
- Errores transitorios: timeouts, un servicio temporalmente no disponible, límites de tasa (rate limits) o cortes de red. Suelen resolverse solos si se vuelve a intentar más tarde.
- Errores permanentes: datos inválidos, un producto que no existe en el sistema destino, credenciales vencidas o una regla de negocio que rechaza la operación. Reintentar no cambia el resultado: hace falta corregir algo.
Tratar todos los errores igual es una de las causas más comunes de problemas en producción. Si se reintenta un error permanente, se satura el sistema destino y se ensucian los logs. Si se descarta un error transitorio, se pierde una operación que se hubiera resuelto sola en unos segundos.
Reintentos con criterio
Para los errores transitorios, los reintentos automáticos son la primera línea de defensa. Pero un reintento mal diseñado puede empeorar la situación:
- Backoff exponencial: cada nuevo intento espera más que el anterior (por ejemplo, 5 segundos, luego 30, luego 2 minutos), para darle margen de recuperación a un sistema que ya viene respondiendo mal.
- Jitter: sumarle a cada espera unos segundos al azar. Si el ERP se cae durante un pico y cientos de pedidos fallan juntos, así se evita que todos vuelvan a enviarse a la vez apenas se recupera.
- Límite de intentos: definir cuántas veces se reintenta antes de considerar que la operación necesita intervención.
- Respetar las señales del destino: si una API indica cuándo volver a intentar, usar ese valor en lugar de uno fijo.
Idempotencia: poder reintentar sin duplicar
Reintentar una creación sin controles puede duplicar el pedido 4512. La idempotencia busca que repetir la solicitud no vuelva a producir el mismo efecto. Un timeout no indica por sí solo si el ERP procesó la operación: puede haberlo hecho y haberse perdido únicamente la respuesta.
Algunas formas de lograrlo:
- Enviar un identificador único por operación (idempotency key) que el sistema destino use para reconocer pedidos repetidos.
- Antes de crear un registro, consultar si ya existe por una clave de negocio, como el número de pedido.
- Preferir operaciones del tipo "establecer el stock en 20" en lugar de "restar 3 unidades", cuando el sistema destino lo permite.
Colas y desacople entre sistemas
Cuando un sistema llama directamente a otro de forma sincrónica, cualquier falla del destino se propaga al origen. Incorporar una cola de mensajes entre ambos permite que el origen registre la operación y siga funcionando, mientras un proceso independiente se encarga de entregarla cuando el destino esté disponible.
Este desacople también ayuda a absorber picos de carga, como una campaña comercial o un cierre de mes, sin que un sistema más lento frene al resto de la operación.
La cola de mensajes fallidos
Las operaciones que agotan sus reintentos o fallan por errores permanentes no deberían desaparecer. Conviene enviarlas a una cola de mensajes fallidos (dead letter queue) donde queden guardadas con todo su contexto: qué se intentó hacer, con qué datos, cuántas veces y qué error devolvió el destino. Desde ahí, el equipo puede corregir el dato y reprocesar la operación sin tener que reconstruirla.
Trazabilidad: saber qué pasó con cada operación
Ante un reclamo del tipo "el pedido 4512 no llegó al depósito", el equipo necesita poder responder en minutos, no en horas. Para eso, cada operación debería dejar un rastro consultable:
- Un identificador de correlación que acompañe la operación a través de todos los sistemas que atraviesa.
- Registros de cada paso con fecha, estado, datos relevantes y respuesta del sistema destino.
- Un backoffice o panel de consulta donde las áreas operativas puedan buscar una operación y ver su estado sin depender del equipo técnico.
Profundizamos en qué registrar, qué métricas mirar y cómo diseñar alertas en trazabilidad y monitoreo de integraciones.
Monitoreo y alertas que sirvan
El monitoreo no consiste en alertar cada error individual, sino en detectar cuándo algo se sale de lo normal. Algunas señales útiles:
- Crecimiento de la cola de mensajes fallidos o de operaciones pendientes.
- Aumento de la tasa de errores o de los tiempos de respuesta de un sistema externo.
- Ausencia de actividad cuando debería haberla: si no entró ningún pedido en la última hora en horario comercial, probablemente algo está roto.
Cada alerta debería indicar a quién le corresponde actuar y qué pasos seguir. Una alerta que nadie sabe cómo resolver termina siendo ignorada.
Reprocesar y conciliar
Aun con todo lo anterior, siempre habrá diferencias entre sistemas. Por eso conviene prever dos herramientas desde el diseño:
- Reprocesamiento: la posibilidad de volver a ejecutar una operación o un lote de operaciones de forma controlada, una vez resuelta la causa del error.
- Conciliación periódica: procesos que comparan la información entre sistemas (stock, pedidos, pagos) y reportan las diferencias antes de que se conviertan en un problema para el cliente.
Por dónde empezar
Si ya tenés integraciones en producción, un buen punto de partida es revisar tres preguntas: ¿qué pasa hoy cuando el sistema destino no responde?, ¿se puede reintentar una operación sin duplicarla? y ¿cuánto tarda el equipo en saber qué pasó con una operación puntual? Las respuestas suelen mostrar rápidamente dónde está el mayor riesgo.
Para el pedido 4512, una respuesta útil debería decir si llegó al ERP, cuántas veces se intentó y quién puede resolverlo. Si hoy esa información requiere revisar varios sistemas a mano, ahí hay un primer problema concreto para corregir.