Integraciones en tiempo real con eventos y CDC

Muchas integraciones aún utilizan polling: cada cinco minutos, un sistema pregunta a otro si ha cambiado algo. Es sencillo, pero añade retraso, llamadas vacías y picos de proceso. Cuando varios consumidores consultan el mismo ERP, el coste y la fragilidad aumentan.

En una arquitectura orientada a eventos, el sistema que registra el cambio publica un hecho —pedido aprobado, stock reservado, cliente actualizado— y los interesados ejecutan su parte de forma independiente. La captura de datos modificados, o CDC, permite aplicar el patrón a bases de datos y aplicaciones heredadas que nunca se diseñaron para emitir eventos.

Polling, webhook, evento o CDC

Polling

El consumidor consulta periódicamente una API o tabla. Es razonable con poco volumen, si varios minutos de retraso son aceptables y el origen no ofrece alternativa. Un intervalo corto desperdicia recursos; uno largo mantiene datos obsoletos.

Webhook

El origen llama a una URL del destino al producirse un cambio. Encaja en conexiones punto a punto, por ejemplo un pago aprobado. El receptor valida la firma, responde rápido y procesa después, ya que el proveedor puede repetir la entrega.

Evento

El productor publica en un broker o bus sin conocer a todos los consumidores. Un nuevo servicio se suscribe al mismo hecho sin modificar el emisor. Así se desacoplan automatización, avisos y analítica.

Change Data Capture

CDC lee el registro de transacciones y convierte altas, cambios y bajas en un flujo. Es útil para integrar legados, alimentar buscadores o analítica y sincronizar datos sin lanzar consultas completas contra la base.

Componentes de una arquitectura orientada a eventos

Los productores registran hechos del negocio. El broker recibe, conserva y distribuye mensajes. Los consumidores ejecutan acciones. Un registro de esquemas documenta la forma de cada evento y la telemetría enlaza el recorrido mediante un identificador de correlación.

El evento debe contar algo ocurrido, no dar una instrucción vaga. Pedido confirmado es reutilizable; envía el pedido al almacén acopla a un destino. Debe incluir identificador único, tipo, versión, fecha, origen y referencia al objeto, evitando replicar datos personales innecesarios.

Ejemplo: desde el cobro hasta el envío

El comercio confirma el pago y graba la venta. Con el patrón outbox, la misma transacción añade un evento pendiente. Inventario reserva unidades; el CRM cambia la oportunidad; logística crea la expedición; una automatización envía la confirmación por WhatsApp. Cada consumidor tiene su cola y evoluciona sin bloquear a los demás.

Si el CRM no está disponible, sus mensajes esperan y se reintentan, mientras el almacén continúa. Cuando vuelve, procesa el retraso. Una mensaje que siempre falla pasa a una cola de excepciones con el contexto necesario para corregirlo y volver a procesarlo.

Fiabilidad: repetir la entrega sin duplicar el negocio

Numerosos brokers ofrecen entrega al menos una vez. Por eso, el consumidor tiene que ser idempotente: recibir el mismo evento dos veces deja el mismo resultado que recibirlo una. Una clave de idempotencia, una restricción única o un registro de mensajes evita cobros, avisos o movimientos de stock duplicados.

Los reintentos necesitan espera progresiva y límite. Los fallos transitorios pueden repetirse; los datos inválidos requieren revisión. La cola de mensajes muertos no es una papelera: necesita alerta, responsable y un mecanismo de reproceso.

Orden y concurrencia

No suele ser necesario un orden global. Normalmente basta conservar la secuencia por pedido o cliente. Particionar por la clave adecuada mantiene ese orden sin limitar toda la plataforma. Ante cambios simultáneos, el consumidor debe rechazar versiones antiguas o utilizar control optimista.

Evolución del esquema

Los eventos duran más que una versión del software. Añada campos de manera compatible, defina valores predeterminados y no cambie el significado de propiedades existentes. Las pruebas de contrato en CI evitan que un productor rompa silenciosamente a muchos consumidores.

Outbox: unir la base de datos y la mensajería

Guardar un pedido y publicar un mensaje son dos operaciones. Si solo una funciona, el sistema queda incoherente. Transactional outbox guarda el dato y el evento en la misma transacción; otro proceso publica la outbox y marca el envío. Junto con la idempotencia, tolera reinicios sin perder hechos.

Si no se puede modificar la aplicación, CDC puede leer esta tabla o el log de cambios. Aun así, una columna actualizada no es automáticamente un evento de negocio. Una capa de transformación debe filtrar ruido, mantener nombres estables y retirar campos que no deberían circular.

Datos en tiempo real para agentes y automatizaciones

Los agentes de IA deciden mejor con contexto reciente. Durante 2026, AWS y Google Cloud han destacado patrones donde cambios y streams activan agentes en lugar de depender de consultas tardías. Un evento de retraso puede iniciar un análisis, reunir pedido, ruta y contrato y proponer una acción al operador.

El evento no debe conceder autonomía ilimitada. Reglas deterministas validan importes, permisos y acciones críticas; una persona aprueba decisiones con impacto financiero, contractual o de seguridad.

Seguridad, privacidad y gobierno

identidades separadas para productores y consumidores;
permisos por tema, entorno y finalidad;
cifrado en tránsito y en reposo;
identificadores en lugar de datos personales completos;
retención, borrado y residencia definidos;
auditoría de accesos y cambios de esquema;
firma y protección contra replay para webhooks.

Un evento puede multiplicar copias. El diseño debe incorporar RGPD desde el inicio: minimización, trazabilidad y mecanismos de rectificación o supresión cuando correspondan.

Observabilidad de extremo a extremo

No basta con saber que el broker está activo. Hay que medir cuánto tarda un cambio en producir cada resultado. Son esenciales el identificador de correlación, el retraso por consumidor, la edad del mensaje más antiguo, los errores, reintentos y el tamaño de la cola de excepciones.

Además de métricas técnicas, un panel puede mostrar “pago a expedición” o “alta a primera atención”. Así se valora la integración por el resultado operativo, no por el número de mensajes.

Cuándo no utilizar eventos

Una llamada síncrona es mejor si el usuario necesita la respuesta para continuar, como comprobar saldo antes de confirmar. Un polling moderado puede bastar para un informe diario. Las colas tampoco arreglan datos deficientes ni eliminan la necesidad de contratos claros.

No conviene crear decenas de temas antes de comprender el dominio. Empiece con un flujo comercial relevante, defina propietario y nivel de servicio y amplíe con datos de volumen, dependencias y beneficio.

Plan de implantación

mapear el evento, productores, consumidores y retraso actual;
elegir webhook, broker o CDC según el origen;
definir esquema, idempotencia, orden y reintentos;
implementar outbox o un mecanismo equivalente;
añadir seguridad, correlación, alertas y cola de excepciones;
comparar ciclo, errores, llamadas y coste antes de ampliar.

ProativaIA crea software a medida, aplicaciones y automatizaciones inteligentes conectadas con ERP, CRM, pagos y canales de atención. Podemos diseñar un piloto orientado a eventos, integrar legados con CDC y aportar observabilidad desde el primer flujo.

Integraciones en tiempo real: cómo los eventos y CDC conectan sistemas sin polling