Tres preguntas antes de elegir
- ¿Qué sistema es la fuente de verdad de cada dato? El precio puede mandar en el ERP, el stock en el sistema de almacén y el estado del pago en la pasarela. Si dos sistemas creen ser dueños del mismo dato, terminarán sobrescribiéndose.
- ¿Qué tan actualizada debe estar la información? Segundos, minutos u horas. La respuesta cambia completamente la arquitectura.
- ¿Qué debe pasar si el otro sistema no está disponible? Bloquear, esperar, guardar para después o continuar con información anterior.
Topologías: cómo se conectan los sistemas
| Topología | Cómo funciona | Ventajas | Limitaciones |
|---|---|---|---|
| Punto a punto | Cada sistema se conecta directamente con los que necesita. | Simple con pocos sistemas. | Con n sistemas puede haber hasta n(n−1)/2 conexiones: con 6 sistemas, hasta 15. |
| Capa central de integración | Los sistemas se conectan a una capa que traduce y distribuye. | Un solo lugar para mapeos, monitoreo y cambios. | La capa es un componente crítico que requiere cuidado. |
| Eventos (publicación/suscripción) | Un sistema publica «ocurrió algo» y los interesados se suscriben. | Bajo acoplamiento; agregar consumidores no afecta al emisor. | Más difícil de seguir de punta a punta; requiere buena observabilidad. |
En la práctica se combinan: una capa central que, internamente, publica eventos para los procesos que no necesitan respuesta inmediata.
Estilos de comunicación
| Criterio | Síncrono (solicitud/respuesta) | Asíncrono (colas o eventos) | Por lotes (archivos) |
|---|---|---|---|
| Actualización | Inmediata | Segundos a minutos | Según la frecuencia programada |
| Acoplamiento | Alto: ambos deben estar disponibles | Bajo: el mensaje espera en la cola | Bajo |
| Si el receptor está caído | El emisor recibe un error | Los mensajes se acumulan y se procesan después | Se procesa en la siguiente ejecución |
| Complejidad | Baja | Media: colas, reintentos, duplicados | Baja a media: formatos y cargas parciales |
| Uso típico | Consultar stock al momento de vender | Registrar ventas en el ERP | Cargas masivas, conciliaciones diarias |
Un ejemplo de decisión
Supongamos una tienda online, un sistema de gestión (ERP) que es la fuente de verdad del stock y un POS en una tienda física. Analicemos cada flujo por separado:
| Flujo | Estilo elegido | Razonamiento |
|---|---|---|
| Mostrar stock en la tienda online | Copia local sincronizada periódicamente | Consultar al ERP en cada visita lo sobrecargaría; unos minutos de desfase son aceptables al navegar. |
| Confirmar stock al pagar | Síncrono, con tiempo de espera corto | Es el momento en que un desfase genera una venta sin producto. |
| Registrar la venta en el ERP | Asíncrono con cola | No hace falta que el cliente espere; si el ERP está lento, la venta se registra después. |
| Ventas del POS hacia el ERP | Según lo que permita el POS | Si solo exporta archivos, por lotes; si tiene API o eventos, asíncrono. |
| Conciliación de ventas | Por lotes, diario | Detecta diferencias que los flujos automáticos no vieron. |
Un mismo par de sistemas puede comunicarse con estilos distintos según el flujo. Elegir un único estilo para todo suele forzar soluciones incómodas.
Contratos de integración
Un contrato documenta lo que cada lado puede esperar del otro: campos, tipos, obligatoriedad, formatos de fecha y moneda, identificadores, códigos de error y comportamiento ante duplicados. Sin contrato, cada integración es una interpretación.
{
"specversion": "1.0",
"type": "com.empresa.ventas.pedido_creado",
"source": "/servicio-ventas",
"id": "evt_7f9c21b0",
"time": "2026-10-03T18:30:00Z",
"datacontenttype": "application/json",
"data": {
"version_esquema": "2.1",
"id_pedido": "1042",
"monto_centavos": 45000,
"moneda": "PEN"
}
}- Cambios compatibles: agregar campos opcionales no debería romper a nadie, siempre que los consumidores ignoren los campos que no conocen.
- Cambios incompatibles: renombrar, eliminar o cambiar el significado de un campo requiere una nueva versión y un periodo de convivencia.
- Ejemplos reales: incluir ejemplos de mensajes en la documentación evita malentendidos que ninguna descripción resuelve.
Identificadores y correspondencias
Cada sistema tiene sus propios identificadores. Para actualizar un registro en lugar de duplicarlo, la integración necesita una tabla de correspondencias: «el cliente 548 de la tienda es el C-00912 del ERP». Esta tabla debe crearse con la integración, no después del primer problema de duplicados.
Errores y reprocesos
En integraciones asíncronas, los mensajes que fallan repetidamente no deben bloquear la cola ni perderse. Se mueven a una cola de mensajes fallidos, donde alguien puede revisarlos, corregir la causa y reprocesarlos. Para eso, el procesamiento debe ser idempotente: reprocesar un mensaje que ya se había aplicado parcialmente no debe duplicar nada.
Si la integración es por archivos
Los archivos siguen siendo una opción válida, especialmente con sistemas antiguos. Para que sean confiables:
- Usa nombres únicos (con fecha y secuencia) y registra qué archivos ya se procesaron.
- Incluye totales de control (cantidad de registros, suma de montos) para detectar archivos incompletos.
- Escribe el archivo con un nombre temporal y renómbralo al terminar, para que nadie lea un archivo a medio escribir.
- Define qué pasa si una parte de los registros es inválida: rechazar el archivo completo o procesar los válidos y reportar el resto.
- Haz que la carga sea idempotente: cargar dos veces el mismo archivo no debe duplicar datos.
Errores frecuentes
- No definir la fuente de verdad de cada dato.
- Usar integración síncrona para todo y encadenar la disponibilidad de todos los sistemas.
- No guardar correspondencias de identificadores.
- Asumir que los mensajes llegan una sola vez y en orden.
- Cambiar un contrato sin versionarlo.
- No tener forma de reprocesar mensajes fallidos sin intervenir la base de datos.
Preguntas frecuentes
¿Siempre conviene una capa central de integración?
No. Con dos o tres sistemas y pocos flujos, la integración directa puede ser suficiente y más simple. La capa central se justifica cuando crece el número de sistemas o cuando se necesita un punto único de monitoreo y transformación.
¿Las colas garantizan que no se pierdan datos?
Reducen mucho el riesgo, pero dependen de la configuración: persistencia de mensajes, confirmación de procesamiento y manejo de mensajes fallidos. Además, la mayoría entrega «al menos una vez», por lo que el consumidor debe tolerar duplicados.
¿Cómo sé si una integración por lotes es suficiente?
Pregunta qué pasa si un dato llega con el retraso del lote. Si la respuesta es «nada grave», los lotes suelen ser la opción más simple y robusta.