Event Driven Architecture

¿Qué es?

La arquitectura dirigida por eventos o simplemente EDA (por sus siglas en inglés) es una
arquitectura asíncrona y distribuida, pensada para crear aplicaciones altamente escalables.

En una arquitectura EDA los componentes no se comunican de forma tradicional, en el cual

se establece comunicación de forma síncrona, se obtiene una respuesta y se procede con
el siguiente paso. En esta arquitectura, se espera que las aplicaciones disparen diversos
“eventos” para que otros componentes puedan reaccionar a ellos, procesarlos y
posiblemente generar nuevos eventos para que otros componentes continúen con el
trabajo.

Un evento lo podemos definir como un cambio significativo en el estado de la aplicación, ya

sea por un dato que cambio o alguna acción concreta en el sistema que merece la pena ser
observada para tomar acciones en consecuencia.

Como se puede observar en la imagen, todo inicia con la llegada de un nuevo evento al
componente Event Bus, el cual es un componente que se encarga de administrar todos los
eventos de la arquitectura. El Event Bus se encargará de recibir el evento y colocarlo en los
Event Channels, las cuales son básicamente una serie de Colas (Queues) o Temas
(Topics) sobre los cuales habrá ciertos componentes a la escucha de nuevos mensajes.

Por otra parte, los Event Processing son componentes de negocio que están a la escucha
de nuevos eventos depositados en los Event Channels. Los Event Processing son los
encargados de procesar los eventos, es decir, realizar acciones concretas sobre el sistema,
como crear, actualizar o borrar algún registro, finalmente, el proceso puede terminar de
forma silenciosa, o puede generar un nuevo evento para que otro componente lo tome y
continúe con el procesamiento.

Un punto importante a tomar en cuenta es que todos los Event Processing son
componentes distribuidos, lo que quiere decir que están totalmente desacoplados del resto
y que el funcionamiento de uno no afecta al resto. De esta forma, cada Event Processing
administra sus propias transacciones, lo que hace difícil mantener la atomicidad de la
transacción en una serie de eventos, por lo que es un punto importante a tomar en cuenta al
momento de trabajar con esta arquitectura.

El patrón EDA consta de dos topologías principales, el mediador y el intermediario. La

topología de mediador se usa comúnmente cuando necesita orquestar varios pasos dentro
de un evento a través de un mediador central, mientras que la topología de intermediario se
usa cuando desea encadenar eventos juntos sin el uso de un mediador central. Debido a
que las características de la arquitectura y las estrategias de implementación difieren entre
estas dos topologías, es importante comprender cada una para saber cuál se adapta mejor
a su situación particular.

Topología con Mediador.

La topología de mediador es utilizada para procesar eventos complejos, donde el éxito de

la operación requiere de una serie de pasos definidos y un orden de ejecución exacto, lo
que en EDA conocemos como orquestación.

El mediator es un componente que toma el evento primario y fracciona un evento en

eventos más pequeños para ser procesados por varios Event Processing, de esta forma,
cada Event Processing realiza una pequeña parte de la tarea de forma asíncrona.
Adicionalmente, el mediador, podrá ejecutar todos los pasos en forma asíncrona, o podrá
requerir que ciertos eventos sean procesados antes de proceder con el resto de pasos. En
este sentido, el mediador no implementa nada de lógica de negocio ni transacciona con los
sistemas, sino que solo se encarga de orquestar los eventos para llevar un orden adecuado
de ejecución.

Topología con Intermediario (broker).

La topología de broker es utilizada para procesar eventos simples, en los cuales no es
necesario orquestar una serie de pasos para llegar al objetivo, en su lugar, los Event
Processing toman los mensajes directamente de los Event Channels y pueden publicar
nuevos eventos para que otros Event Processing continúen procesando los siguientes
eventos.

Características de una EDA.

A continuación se enlistan las características de un EDA, la cuales se pueden convertir en

ventajas o desventajas solo cuando se analiza la problemática que se pretende resolver,
mientras tanto, son solo características:

• Se conforma de varios componentes distribuidos que reaccionan únicamente a Eventos.

• Usa sistemas de mensajería asíncrona como Colas (Queues) y Tópicos (Topics).

• Existe un componente intermediario para administrar los mensajes de forma segura, como
son los Message-Oriented-Middleware (MOM) o Service Bus.

• Son con frecuencia utilizados en arquitecturas SOA y Microservicios.

• Completar una operación de negocio requiere por lo general del involucramiento de varios
componentes que realizan una pequeña parte de la tarea global.

• Tanto el productor cómo los consumidores están totalmente desacoplados entre sí,
incluso, no tienen conocimiento de si existe tal consumidor.
Ventajas

1. Escalabilidad: La escalabilidad es uno de los puntos más fuertes de esta

arquitectura, pues permite que cada consumidor (Event Consummer) puede
escalar de forma independiente y reduce al máximo el acoplamiento entre los
componentes.

2. Despliegue: Debido al bajo acoplamiento entre los componentes, es posible el

despliegue sin preocuparse por dependencias o precondiciones, al final, los
componentes solamente se suscriben para recibir eventos y reaccionar ante ellos.

3. Performance: Esta es una ventaja cuestionable, ya que al igual que en REST, EDA
necesita pasar por una serie de pasos para completar una tarea, agregando retrasos
en cada paso, desde colocar el evento por parte del productor, esperar a que el
consumidor lo tome, y generar nuevos eventos, sin embargo, la naturaleza
asíncrona de EDA hace que esta desventaja se supere mediante el procesamiento
en paralelo.

4. Flexibilidad: EDA permite responder rápidamente a un entorno cambiante, debido a

que cada componente procesador de eventos tiene una sola responsabilidad y está
completamente desacoplado de los demás, de esta forma, si ocurre un cambio, se
puede aislar en un solo componente sin afectar al resto, además, si un nuevo
requerimiento es requerido, solo es necesario regresar un nuevo tipo de procesador
de eventos que escuche un determinado tipo de evento.

Desventajas

1. Testabilidad: Una arquitectura distribuida y asíncrona agrega cierta complejidad a las

pruebas, pues no es posible generar un evento y esperar un resultado para validar el
resultado, en su lugar, es necesario crear pruebas más sofisticadas que creen los
eventos y esperen la finalización del procesamiento del evento inicial más toda la
serie de eventos que se podrían generar como consecuencia del evento inicial para
validar el resultado final.

2. Desarrollo: Codificar soluciones asíncronas es complicado, pero aún más, es la

necesidad de crear manejadores de errores más avanzados que permitan
recuperarse en una arquitectura asíncrona, donde la falla en un procesador no
significa la falla en el resto, lo que puede ocasionar la inconsistencia entre los
sistemas.

3. El emisor no tiene garantía, ni pretende saber, que los destinatarios hayan tratado
los eventos, ya que el patrón usado es Fire&Forget (no hay garantía de que todos
los clientes consuman sus eventos).
Cuando utilizar EDA

EDA es una arquitectura muy robusta que permite crear soluciones altamente escalables,
pero tiene como principal problemática su dificultad para programar, la cual puede ser
mayor a las ventajas que podría ofrecer si se implementa de forma inadecuada, es por ello
que debemos pensar en EDA solo cuando sabes que nuestra aplicación está planeada para
un rápido crecimiento o para un volumen de transacciones muy alto, en otro caso,
podríamos estar haciendo una sobre ingeniería que nos podría salir muy caro.

Entonces podemos definir que debemos utilizar EDA cuando:

1. Pensamos crear aplicaciones altamente escalables.

2. Necesitamos explotar al máximo la capacidad de procesamiento paralelo, concurrente y

asíncrono.

3. Donde una respuesta síncrona no es obligatoria.

4. En arquitecturas donde es necesario producir eventos en tiempo real para que otros
suscriptores puedan actuar en consecuencia en tiempo real.

Conclusiones

EDA es sin lugar a duda una de los estilos arquitectónicos más escalables que existe y
permite que empresas puedan atender a millones de solicitudes sin degradar el rendimiento
de sus sistemas, ya que permite dividir el trabajo en diversos procesadores de mensajes
que trabajan de forma totalmente aislados y desacoplados del resto, sin embargo,
implementar este patrón no es fácil, pues requiere un esfuerzo mucho mayor que una
arquitectura síncrona, y requiere una mejor preparación de la solución.

Otro de los puntos a considerar al implementar EDA es que, debemos tener un

conocimiento más profundo de la solución de negocio que vamos a desarrollar, pues
necesitamos ese conocimiento para saber cómo dividir la aplicación en los diversos
consumidores, ya que de lo contrario podemos crear módulos del sistema que no sean lo
suficientemente desacoplados del resto.

Por último, debemos de entender que en una arquitectura EDA no existe el concepto de
transacciones, pues cada consumidor maneja de forma independiente sus propias
transacciones, por lo que si un paso de la cadena de procesamiento falla, no implicará el
rollback en todos los consumidores, es por ello que debemos de tener manejadores de
errores muy avanzados que permiten a un proceso recuperarse en caso de fallo o de plano
que levante una serie de nuevos eventos para hacer el rollback en los otros consumidores.
De igual manera considerar que en EDA no hay garantía que un evento sea procesado, ya
sea porque no hay consumidores para un determinado evento o por un error en el diseño.
Referencias

https://www.youtube.com/watch?v=iM7aq8tWTmc

https://www.youtube.com/watch?v=gX0DUO171jc

https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/
ch02.html