La arquitectura orientada a eventos (EDA, por sus siglas en inglés) es una forma de construir software en la que las partes de un sistema se comunican anunciando que algo ha ocurrido, en lugar de llamarse directamente entre sí. Un componente publica un evento, como «factura pagada» o «contrato firmado». Cualquier otro componente al que le interese reacciona a él. Ninguna de las partes necesita saber que la otra existe.

Para una empresa SaaS, esto importa mucho más allá de la ingeniería. La misma idea está detrás de traspasos limpios entre CRM y finanzas, de una automatización fiable y de agentes de IA que actúan sobre datos actuales. Esta guía explica cómo funciona la EDA, en qué se diferencia un bus de eventos de una cola, cómo evitar los fallos más habituales y dónde encaja y dónde no.

Resumen

Índice

Qué es la arquitectura orientada a eventos

La guía de arquitectura de Microsoft describe este estilo como productores de eventos que generan un flujo de eventos, consumidores de eventos que los escuchan y canales de eventos que llevan los eventos de unos a otros. Ese modelo de tres partes es toda la idea. Todo lo demás son detalles sobre la fiabilidad y la velocidad del canal.

El contraste es con el modelo de solicitud/respuesta. En un diseño de solicitud/respuesta, su servicio de facturación llama al CRM y espera una respuesta. Si el CRM va lento o está caído, la facturación se queda bloqueada. En un diseño orientado a eventos, la facturación publica «pago recibido» y sigue adelante. El CRM, el informe de ingresos y el panel de customer success recogen el evento cuando están listos.

De ello se derivan dos propiedades:

Qué se considera un evento

Un evento es una afirmación de un hecho, en pasado. Red Hat lo describe como un registro inmutable de que algo ha ocurrido, a menudo con una marca de tiempo que conserva el orden respecto al sistema que lo produjo. Un evento no se edita después. Si algo cambia, un nuevo evento registra el cambio.

AWS señala que los eventos pueden ser un cambio de estado o una actualización, y pueden transportar el estado o ser identificadores. Dos ejemplos:

Estilo Ejemplo Qué recibe el consumidor
Evento que transporta el estado Suscripción mejorada, con plan, precio, fecha de entrada en vigor e ID de cuenta Todo lo necesario para actuar sin una segunda consulta
Evento como identificador Pedido enviado, solo con el ID del pedido Una señal. El consumidor obtiene los detalles del sistema de origen

El primero es cómodo, pero acopla los consumidores a la forma del evento. El segundo mantiene los eventos pequeños, pero obliga a los consumidores a volver al sistema de origen, lo que plantea la pregunta de qué sistema es la fuente de referencia. Volvemos sobre ello más abajo, porque es donde más tropiezan la mayoría de los stacks de operaciones de SaaS.

Un comando no es un evento. «Enviar la factura» es una instrucción dirigida a un destinatario concreto. «Factura enviada» es un hecho al que cualquiera puede reaccionar. Mezclar ambos es un error de diseño habitual y reconstruye sin darse cuenta el acoplamiento estrecho que se quería eliminar.

Cómo funciona un sistema orientado a eventos, paso a paso

La documentación de Google Cloud describe el flujo: los productores generan eventos, un router o broker los recibe y filtra, y después los distribuye a los consumidores según suscripciones o desencadenadores. En la práctica:

  1. Ocurre algo. Una oportunidad pasa a «Closed Won» en el CRM.
  2. El productor publica un evento. El evento expone el hecho y el registro al que se refiere.
  3. El broker lo enruta. Filtra el evento y lo entrega a cada suscriptor.
  4. Los consumidores reaccionan de forma independiente. Finanzas crea un borrador de factura. Customer Success abre un plan de onboarding. Un proceso de aprovisionamiento prepara los accesos.
  5. Cada consumidor confirma la recepción. El broker sabe que el evento se ha gestionado y puede reintentarlo si no fue así.

IBM plantea el mismo patrón como publicación, captura, procesamiento y almacenamiento de eventos, y señala que el valor de un evento puede cambiar con el tiempo. Un evento de «nuevo lead» merece una respuesta en minutos. Un año después sirve sobre todo para el análisis.

Arquitectura orientada a eventos y microservicios

Con frecuencia se tratan como lo mismo. No lo son. Los microservicios describen cómo se divide una aplicación en servicios pequeños que se despliegan de forma independiente. La EDA describe cómo se comunican esos servicios. Puede haber microservicios que se llamen entre sí de forma síncrona, y puede haber un monolito que publique eventos internamente.

Ambos funcionan bien juntos. La guía de Google señala que los microservicios pueden reaccionar de forma asíncrona a los eventos y solo necesitan conocer el formato del evento, no la lógica de negocio de los demás. Ese formato compartido es el contrato. Todo lo que hay detrás puede cambiar.

La documentación de Microsoft describe el patrón típico como microservicios que publican un evento cuando ocurre algo relevante, mientras otros microservicios se suscriben.

Bus de eventos, cola y stream

Estos tres términos generan la mayor confusión, y la elección cambia el comportamiento de su sistema.

Bus de eventos (publicación/suscripción). Un bus de eventos es un mecanismo en el que los publicadores anuncian eventos y los suscriptores los reciben. Microsoft explica que puede implementarse sobre una infraestructura de mensajería, como una cola o un service bus que admita publicación/suscripción asíncrona. Es decir, una cola puede ser uno de los componentes de un bus. El bus es la intención. La cola es una forma de llevarla a cabo.

Cola. Una cola retiene los mensajes hasta que un worker los toma. Normalmente, cada mensaje lo gestiona un solo consumidor. Las colas son la herramienta adecuada para repartir trabajo entre workers y para absorber picos de carga. La guía de integración de Azure incluye poner mensajes en cola cuando un back end no está disponible entre los motivos para usar un broker.

Flujo de eventos. Azure distingue la publicación/suscripción del streaming. En la publicación/suscripción, una vez recibido el evento no se conserva en un registro duradero, así que los nuevos suscriptores no ven los eventos pasados. En el streaming, los eventos se escriben en un registro duradero y estrictamente ordenado dentro de cada partición, y los clientes leen del registro, pueden incorporarse en cualquier momento y reproducir los eventos.

Cola Bus de publicación/suscripción Flujo de eventos
Entrega Un consumidor por mensaje Todos los suscriptores Cualquier lector, desde cualquier punto
Eventos pasados Se eliminan tras procesarse No disponibles para nuevos suscriptores Se conservan y se pueden reproducir
Uso típico Reparto de trabajo, almacenamiento en búfer Notificar a varios sistemas Historial, analítica, reconstrucción del estado

Una regla práctica: si necesita que varios sistemas reaccionen al mismo hecho, utilice publicación/suscripción. Si necesita que un worker realice una tarea, utilice una cola. Si necesita historial o la capacidad de reconstruir un sistema posterior, utilice un flujo de eventos. Red Hat añade que no existe una solución válida para todos los casos, así que conviene elegir la tecnología según el tipo de evento.

¿Es Kafka una arquitectura orientada a eventos?

No. Kafka es una tecnología con la que se puede construir una. La documentación de Apache Kafka la describe como una plataforma de streaming de eventos: captura eventos en tiempo real, los almacena de forma duradera, los procesa y los enruta a otros sistemas. Eso la sitúa como un flujo de eventos en la tabla anterior.

Una arquitectura es un conjunto de decisiones de diseño: cuáles son los eventos, quién es su responsable, cómo se aíslan los consumidores y qué ocurre ante un fallo. Esas decisiones se pueden tomar y ejecutar sobre un bus gestionado en la nube, un servicio de colas o Kafka. También se puede ejecutar Kafka y seguir teniendo un sistema fuertemente acoplado si cada servicio depende de los eventos internos de otro. Elija la herramienta después de haber definido los eventos y el volumen que realmente espera.

Integración y automatización orientadas a eventos

Aquí es donde la EDA resulta relevante para los responsables de operaciones y no solo para los ingenieros.

Integración

La mayoría de las empresas SaaS conectan los datos de su CRM, facturación, soporte y producto mediante sincronizaciones punto a punto. Cada nueva herramienta añade otra conexión que mantener. Azure recomienda la comunicación asíncrona a través de un broker de mensajes en lugar de llamadas síncronas directas, por cuatro motivos que enumera: desacoplar aplicaciones, difundir a varios consumidores, seguir de forma fiable flujos de trabajo de larga duración y poner mensajes en cola cuando un back end no está disponible.

La ventaja se nota al añadir un sistema. Con un servicio de publicación/suscripción, se pueden añadir nuevos suscriptores sin actualizar al emisor. Incorporar una nueva herramienta de analítica no exige modificar su CRM.

Automatización

La automatización basada en eventos significa que un proceso de negocio se inicia porque ha ocurrido algo, y no porque alguien haya pulsado un botón o se haya ejecutado un proceso nocturno. La guía de flujos de ServiceNow ofrece un método práctico: identificar el desencadenador, planificar la lógica, seleccionar las acciones e identificar la lógica reutilizable. También recomienda mantener los flujos acotados y usar un verbo por acción.

Cuando un proceso abarca varios servicios, Microsoft señala que los sistemas basados en eventos suelen emplear patrones de coreografía y de orquestación de sagas para coordinar el flujo. En la coreografía, cada servicio reacciona a los eventos y emite los suyos. En la orquestación, un coordinador indica a cada paso qué hacer y supervisa todo el proceso. Para un primer proyecto, un flujo orquestado suele ser más fácil de leer y de auditar.

Un ejemplo sencillo en una empresa SaaS:

Buenas prácticas y retos habituales

Azure enumera los principales retos: consistencia eventual, gestión asíncrona de errores, pérdida de datos, observabilidad y pruebas, demasiados eventos o eventos excesivamente consolidados, y evolución de los esquemas. Cada uno tiene una práctica adecuada.

  1. Planifique la consistencia eventual. Los sistemas discreparán brevemente. Decida qué sistema es la referencia para cada dato y haga que los demás lo sigan.
  2. Añada un gestor de errores específico. Los eventos fallidos necesitan un lugar adonde ir y alguien que los revise.
  3. Conserve los eventos hasta que se confirme su recepción. Esto protege frente a la pérdida de datos cuando un consumidor no está disponible.
  4. Utilice identificadores de correlación. Un único ID presente en cada paso permite rastrear una acción de un cliente a través de varios sistemas.
  5. Equilibre la granularidad de los eventos. Un evento por cada cambio de campo genera ruido. Un único evento gigante para todo vuelve a crear acoplamiento.
  6. Versione los esquemas pronto. Los formatos de los eventos cambiarán. Decida cómo hacerlo antes de tener veinte consumidores.

A estas prácticas añadiríamos tres hábitos operativos: nombrar los eventos en pasado, asignar un único responsable a cada tipo de evento y dejar por escrito qué consumidores dependen de él.

Dónde no encaja el diseño orientado a eventos

La arquitectura orientada a eventos (EDA) no es la respuesta a todos los problemas. Sea explícito sobre sus límites antes de comprometerse:

La misma lógica se aplica a la IA. Un asistente de IA que lee y actúa sobre sus sistemas es consumidor y productor de eventos. Si lee datos inconsistentes o actúa sin un límite de permisos, tiene una forma más rápida de cometer errores.

Dónde se cruza con los agentes de IA y el cumplimiento normativo

Los agentes de IA que extraen datos (preguntar, informar, consultar) y los envían (actualizar un registro, desencadenar un proceso, conceder accesos) se comportan como participantes de un sistema orientado a eventos. Necesitan una fuente fiable que leer, un conjunto claro de acciones permitidas, aprobación para los pasos sensibles y un registro de lo que han hecho. Un registro de eventos es un lugar natural para ese registro.

Operador revisando el registro de eventos de un agente de IA

Para las empresas europeas, el GDPR, la NIS2 y el EU AI Act afectan al diseño de estos sistemas. En términos generales, influyen en qué datos personales circulan por los eventos, en cómo se organizan la seguridad y la gestión de incidentes, y en cómo se gobiernan y documentan los sistemas de IA. Trátelos como requisitos de diseño desde el principio y consulte a un asesor jurídico sobre cómo se aplican a su caso concreto. Ninguna decisión de arquitectura, por sí sola, hace que un sistema cumpla la normativa.

Nuestra perspectiva

La mayoría de las empresas SaaS con las que hablamos no tienen un problema de eventos. Tienen un problema de responsabilidad. Varios equipos usan IA, varias herramientas guardan una versión del cliente y nadie es responsable de decidir cuál es la correcta.

Por eso trabajamos en un orden fijo. Primero, la base de datos (data foundation): los datos de CRM y finanzas como fuente de verdad acordada. Después, la capa de IA, que conecta esos datos con el asistente que su equipo ya utiliza. Luego, agentes departamentales para Finanzas, Ventas y Customer Success. Los eventos son útiles en las tres capas, pero solo ayudan cuando los hechos que transportan están acordados.

También adoptamos un proceso cada vez, empezando por el más costoso. Un proceso de renovación o el traspaso de factura a cobro es un mejor primer proyecto orientado a eventos que una reconstrucción de toda la empresa. Usted ve el resultado, su gente aprende el patrón y el siguiente proceso resulta más barato.

Como gestionamos las operaciones además de diseñar los sistemas, nos importan los aspectos aburridos: permisos, aprobaciones, pistas de auditoría y un traspaso en el que usted es propietario del código, la documentación y la infraestructura.

Claus Nielsen

Cómo empezar en su propia empresa

No necesita elegir primero un broker. Empiece por estas preguntas:

  1. ¿Qué proceso le cuesta más en trabajo manual, retrasos o errores?
  2. ¿Cuáles son los dos o tres eventos que lo inician (por ejemplo, oportunidad cerrada, factura vencida, renovación próxima)?
  3. ¿Qué sistema es la fuente de verdad de los datos de esos eventos?
  4. ¿Quién es responsable de cada definición de evento?
  5. ¿Qué pasos necesitan aprobación humana?

Si no puede responder a la tercera pregunta, lo primero es la base de datos (data foundation). Si puede, un pequeño piloto sobre un proceso le mostrará si un enfoque orientado a eventos resulta rentable.

Cómo podemos ayudarle

Si su equipo usa IA pero nadie es responsable de ella, podemos ayudarle a decidir dónde compensa y a construirla en el orden adecuado. Nuestro AI Readiness Assessment está disponible desde €4,500 y analiza sus datos, sistemas y procesos antes de construir nada. Si desea un liderazgo continuado, el servicio de Chief AI Officer fraccional parte de €1,500 al mes.

Los desarrollos se facturan al 30% del ahorro del primer año, medido y demostrado, o a un precio fijo acordado antes de empezar el trabajo. También puede reservar una llamada de descubrimiento gratuita de 30 minutos a través de nuestro sitio web. Nuestros agentes de IA para Finanzas, Ventas y Customer Success muestran cómo es la capa departamental una vez que la base está lista.

FAQ

¿Qué es la arquitectura orientada a eventos en términos sencillos?

Es un diseño en el que los componentes de software anuncian que ha ocurrido algo y otros componentes reaccionan. El emisor no sabe quién escucha. Esto permite añadir o cambiar sistemas sin reescribir los que producen los eventos.

¿Cuál es la diferencia entre un bus de eventos y una cola de mensajes?

Una cola suele entregar cada mensaje a un solo trabajador. Un bus de eventos entrega cada evento a todos los suscriptores. Un bus puede construirse sobre una infraestructura de colas, por lo que la diferencia está en la intención y en el patrón de entrega, no siempre en el producto.

¿Es la arquitectura orientada a eventos lo mismo que los microservicios?

No. Los microservicios tratan de cómo se divide una aplicación en servicios. La arquitectura orientada a eventos trata de cómo se comunican las partes. A menudo se usan juntas, pero cada una puede existir sin la otra.

¿Cuándo debería una empresa SaaS usar la automatización basada en eventos?

Úsela cuando un proceso de negocio deba iniciarse a partir de un hecho, como un acuerdo cerrado o una renovación próxima, y varios equipos o sistemas tengan que reaccionar. Empiece por un proceso costoso y asegúrese de que los datos de origen estén acordados de antemano.

Fuentes