Industria y datos

Arquitecturas orientadas a eventos

Un hecho de negocio se publica una sola vez y cada sistema interesado lo procesa a su ritmo, sin bloquear al resto si uno falla.

Cuando un pedido se confirma, varias cosas deberían pasar casi a la vez: reservar existencias, avisar al almacén, actualizar el portal del cliente y emitir un documento. Encadenarlas con llamadas directas entre aplicaciones funciona hasta que una de ellas tarda o se cae, y entonces todo se detiene. Una arquitectura orientada a eventos publica ese hecho una sola vez y deja que cada sistema interesado lo procese a su ritmo, apoyándose en colas que absorben picos y reintentan cuando algo falla. La clave del diseño no es la herramienta de mensajería, sino responder antes a preguntas incómodas: cuánto retraso es aceptable, qué pasa si un mensaje llega dos veces y quién se entera cuando uno no llega.

Explicar mi proceso Ver un ejemplo

Capas · Arquitecturas de eventosIlustración conceptual

Entrada de datos
- Eventos publicados por aplicaciones
- Captura de cambios o webhooks
Validación
- Esquema versionado del evento
- Identificador único por mensaje
Procesamiento
- Colas por consumidor
- Reintentos espaciados e idempotentes
Control humano
- Revisión de la cola de errores
- Reproceso manual autorizado
Trazas
- Traza correlacionada de extremo a extremo
- Retraso acumulado por cola
Sistemas de salida
- Sistemas destino actualizados
- Alertas por mensajes fallidos

Antes y después

Qué cambiaría en la operación

Ejemplo hipotético: una tienda en línea de recambios cuyo pedido confirmado debe llegar al almacén, a facturación y al aviso por correo al cliente.

01 · Antes
La tienda llama en cadena a cada sistema al confirmar el pedido; si facturación tarda, el cliente espera y a veces el pedido queda registrado a medias.
02 · Sistema propuesto
La tienda publica el evento «pedido confirmado» con un identificador único, y almacén, facturación y avisos lo consumen desde sus colas con reintentos idempotentes.
03 · Después
Si facturación se detiene, el pedido sigue avanzando en almacén, los mensajes pendientes esperan en su cola y el equipo de operación ve qué falló y lo reprocesa.

Alcance

Qué resuelve y qué no

Qué puede resolver

Desacoplar aplicaciones para que el fallo o la lentitud de una no bloquee a las demás.
Sincronizar datos entre sistemas en tiempo útil sin depender de exportaciones nocturnas.
Repartir trabajo pesado en colas que procesan a su ritmo y absorben picos de actividad.
Dejar un registro de qué eventos ocurrieron, quién los procesó y con qué resultado.

Qué no resuelve

No elimina los retrasos: introduce consistencia eventual y hay que decidir qué pantallas y procesos la toleran.
No es adecuada para operaciones que exigen una respuesta inmediata y confirmada en la misma transacción.
No sustituye a los sistemas de control en tiempo real de planta ni a funciones de seguridad, que tienen requisitos propios.

Escenarios operativos

Cómo funcionaría en la práctica

Ejemplos de lo que se podría diseñar. No describen proyectos realizados.

01
Notificaciones a partir de cambios de estado
Entrada
Eventos de cambio de estado de pedidos, expedientes u órdenes publicados por la aplicación principal.
Procesamiento
Un servicio suscrito filtra los eventos relevantes, consulta las preferencias de cada destinatario y agrupa avisos para no repetirlos.
Salida
Correos, mensajes o avisos en aplicación enviados una sola vez por evento, con registro de entrega o de fallo.
02
Sincronización entre ERP y aplicaciones satélite
Entrada
Altas y modificaciones de clientes, artículos o precios detectadas en el ERP mediante captura de cambios o eventos propios.
Procesamiento
Cada cambio se publica con un identificador único; los consumidores lo aplican de forma idempotente, de modo que recibirlo dos veces no duplica nada.
Salida
Portal, aplicación de campo y tienda actualizados en poco tiempo, con una cola de errores revisable si algún destino rechaza el cambio.
03
Alertas operativas encadenadas
Entrada
Eventos de planta o de monitorización, como una parada de línea, una temperatura fuera de rango o un retraso de envío.
Procesamiento
Reglas sobre ventanas de tiempo correlacionan eventos relacionados y descartan los transitorios antes de generar una alerta.
Salida
Alerta única con el contexto agregado dirigida al responsable de turno, y escalado si nadie la reconoce en el plazo acordado.
04
Colas de trabajo para procesos pesados
Entrada
Solicitudes de generación de documentos, cálculos o procesamiento de ficheros que llegan de forma irregular.
Procesamiento
Las tareas se encolan y varios trabajadores las procesan en paralelo, con reintentos espaciados y un límite tras el cual pasan a revisión.
Salida
Resultados disponibles para el usuario cuando están listos, con estado visible de cada tarea y aviso de las que fallan definitivamente.

Integración

Cómo se conecta con lo que ya existe

Se elige el mecanismo de mensajería según volumen, orden y retención necesarios, desde colas gestionadas en la nube hasta brokers de streaming o MQTT en entornos industriales. Cada evento tiene un esquema versionado y documentado. Las aplicaciones que no publican eventos se integran mediante captura de cambios en base de datos, webhooks o sondeo controlado. La observabilidad se diseña desde el inicio para seguir un evento de extremo a extremo.

Broker o servicio de colas acorde al volumen y a la retención necesaria
Esquemas de eventos versionados y registro de contratos
Captura de cambios o webhooks para sistemas que no publican eventos
Colas de mensajes fallidos con herramientas de revisión y reproceso
Trazas, métricas y alertas por cola, consumidor y retraso acumulado

Modalidades de despliegue que suelen plantearse

Se elige en cada proyecto tras evaluar requisitos y sistemas existentes.

Antes de desarrollar

Datos, validaciones y permisos

Tolerancia acordada a retrasos y a fallos para cada flujo: cuánto puede tardar y qué ocurre si no llega.
Catálogo de eventos con su significado de negocio, su propietario y su esquema.
Identificadores únicos que permitan procesar cada evento de forma idempotente.
Política de reintentos, de retención de mensajes y de tratamiento manual de los fallidos.
Responsable operativo que vigile colas y alertas y sepa cómo reprocesar.

Supervisión

Riesgos, límites y mantenimiento

Sin idempotencia, un reintento puede duplicar pedidos, cobros o avisos; es un requisito, no una mejora opcional.
El orden de los eventos no siempre se preserva; los procesos que dependen de él deben diseñarse con eso en cuenta.
Los flujos asíncronos son más difíciles de depurar; sin trazas correlacionadas, localizar un fallo puede llevar mucho tiempo.
Cambiar un esquema sin versionado rompe a consumidores que nadie recordaba; hace falta gobierno de contratos.

Sectores donde se aplicaría

Cómo se contrata

Para profundizar

Preguntas frecuentes

¿Cuándo no compensa una arquitectura de eventos?

Cuando hay pocas aplicaciones, poco volumen y los procesos necesitan una respuesta confirmada al momento. En esos casos una integración directa bien diseñada suele ser más sencilla de construir, operar y depurar.

¿Qué pasa si un mensaje se pierde o llega dos veces?

Se diseña para ambos casos: los consumidores ignoran los duplicados gracias a identificadores únicos, y los mensajes que no se pueden procesar se apartan a una cola de errores con aviso, en lugar de desaparecer.

¿Hace falta una plataforma de streaming?

No siempre. Muchas necesidades se cubren con colas gestionadas o con un broker sencillo. Una plataforma de streaming tiene sentido cuando hay que conservar y reprocesar grandes volúmenes de eventos o alimentar muchos consumidores independientes.

Cuéntanos qué procesos deben reaccionar a qué hechos

Cuéntanos qué datos y sistemas intervienen en tu proceso. Estudiaremos qué puede automatizarse, cómo se integraría y qué convendría validar antes de desarrollar. Ver todas las capacidades.

Explicar mi proceso

Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.