Cuándo una integración de sistemas deja de escalar

Una integración suele empezar con una necesidad concreta: pasar pedidos al ERP, sincronizar clientes con el CRM o enviar facturas a un proveedor. Funciona, crece y termina sosteniendo más procesos de los que nadie había previsto. El problema no aparece solo cuando aumenta el volumen. También surge cuando cada cambio exige coordinación, los errores generan duplicados y recuperar un mensaje requiere intervención manual.

Una integración deja de escalar cuando el esfuerzo para cambiarla, observarla y recuperarla crece más rápido que el valor que aporta. Antes de sustituirla, conviene identificar qué límite se está alcanzando: capacidad, acoplamiento, fiabilidad u operación.

Escalar no es solo mover más datos

Una conexión puede procesar el mismo número de operaciones y, aun así, volverse frágil. Cada nuevo consumidor amplía el impacto de un cambio de contrato; cada dependencia remota añade latencia y modos de fallo; cada excepción sin dueño aumenta la cola de trabajo manual.

• Capacidad: el flujo acumula retraso en horas punta o agota conexiones, memoria o límites del proveedor.
• Acoplamiento: cambiar un campo obliga a coordinar varios equipos y despliegues.
• Fiabilidad: los reintentos producen duplicados, desorden o más carga cuando el sistema remoto ya está fallando.
• Operación: nadie puede seguir una transacción de extremo a extremo ni repetirla con seguridad.
• Propiedad: no está claro quién decide el contrato, atiende una alerta o reconcilia un dato.

Seis señales de que la integración ha alcanzado su límite

• Los reintentos no tienen un máximo claro. Un fallo temporal se convierte en una tormenta de peticiones y alarga la recuperación.
• La misma operación puede ejecutarse dos veces. No existe una clave de idempotencia ni una regla de deduplicación.
• Los mensajes fallidos desaparecen o solo pueden recuperarse editando datos directamente. No hay destino de errores ni procedimiento de reproducción.
• Una modificación del proveedor rompe varios consumidores. El contrato no está versionado o su compatibilidad no se prueba.
• Los equipos comparan registros a mano. Faltan un identificador de correlación, métricas por etapa y un responsable para cada alerta.
• Publicar un cambio exige detener el flujo o desplegar varios sistemas a la vez. No hay una frontera que permita evolucionar componentes por separado.

Una señal aislada no obliga a rediseñar toda la arquitectura. Varias señales repetidas indican que el coste operativo ya forma parte del problema y debe medirse.

Primero, dibuja el recorrido real

El diagnóstico empieza con un único flujo crítico. Para cada paso, documenta productor, consumidor, contrato, responsable, volumen normal y pico, latencia aceptable, tiempo máximo de espera y qué ocurre cuando falla.

• ¿La operación puede repetirse sin producir un segundo efecto?
• ¿Dónde queda un mensaje que no se puede procesar?
• ¿Cómo se identifica y reproduce una operación concreta?
• ¿Qué sistema es la fuente de verdad de cada dato?
• ¿Qué cambio puede desplegar cada equipo sin coordinarse con los demás?

Este mapa separa síntomas distintos. Una cola puede absorber picos, pero no corrige por sí sola un contrato ambiguo. Un gateway puede proteger una API, pero no resuelve duplicados si la operación no es idempotente.

Elige el patrón según el fallo que quieres contener

Si una llamada síncrona sigue siendo adecuada, define un tiempo máximo de espera y limita los reintentos. AWS recomienda combinar reintentos controlados con espera exponencial y variación aleatoria para evitar que muchos clientes vuelvan a intentarlo al mismo tiempo. También advierte que reintentar en varias capas puede multiplicar la carga.

Fuente: AWS Builders' Library — Timeouts, retries and backoff with jitter

Cuando un servicio permanece degradado, un circuit breaker puede detener temporalmente nuevas llamadas y ofrecer una respuesta alternativa o un fallo rápido. Microsoft señala que el patrón debe acompañarse de monitorización y que sus umbrales dependen del contexto; no es un sustituto del manejo de errores.

Fuente: Microsoft Azure Architecture Center — Circuit Breaker

Para operaciones con efectos —crear un pedido, cobrar o emitir una factura—, una clave de idempotencia permite reconocer un reintento y evitar repetir la acción. Stripe documenta este mecanismo en su API; el diseño equivalente en otro sistema debe definir alcance, caducidad y almacenamiento de las claves sin incluir datos sensibles.

Fuente: Stripe Docs — Idempotent requests

• Cola o evento: desacopla tiempos de procesamiento y absorbe picos cuando el consumidor no necesita responder en la misma llamada.
• Adaptador: aísla cambios frecuentes de un proveedor o de un sistema legacy detrás de un contrato propio.
• Destino de errores y reproducción: conserva el contexto mínimo para investigar y repetir de forma controlada.
• Observabilidad: propaga un identificador de correlación y mide latencia, errores, profundidad de cola y antigüedad del mensaje.

Ejemplo: una sincronización que creció sin una frontera

Imaginemos una sincronización nocturna entre ERP y CRM. Primero copiaba clientes en una dirección. Después añadió contactos, oportunidades y actualizaciones en ambos sentidos. Cuando el CRM respondía lentamente, el proceso completo se reintentaba y creaba registros duplicados. El equipo solo podía averiguar qué ocurrió comparando dos archivos.

Una primera etapa razonable no sería reemplazarlo todo. Podría separar el alta de clientes, asignar una clave idempotente a cada operación, guardar los fallos con su identificador de correlación y ofrecer una reproducción controlada. Durante la coexistencia, una conciliación compara origen y destino. Si la etapa funciona, el mismo límite puede aplicarse a otro flujo; si no, se conserva una ruta de retorno.

Es un ejemplo hipotético. La elección entre llamada, cola, evento o procesamiento por lotes depende de consistencia, latencia, seguridad, coste y capacidades reales de los sistemas.

Checklist antes de rediseñar

• Un flujo prioritario y su responsable están identificados.
• Hay una línea base de volumen, pico, latencia, errores, duplicados y trabajo manual.
• El contrato y la fuente de verdad de cada dato están documentados.
• Timeouts, reintentos, idempotencia y destino de errores tienen reglas explícitas.
• La observabilidad permite seguir una operación de extremo a extremo.
• La migración incluye coexistencia, conciliación, criterios de parada y recuperación.

El objetivo no es añadir más infraestructura, sino recuperar una frontera que los equipos puedan entender, operar y cambiar. Empieza por el flujo cuyo fallo tenga mayor impacto y cuya mejora puedas verificar sin poner en riesgo toda la operación.

Cómo modernizar software legacy sin detener la operación

En Codiloop podemos ayudarte a mapear la integración, localizar su límite y diseñar una primera etapa verificable.