La Arquitectura dirigida por eventos (en inglés, Event-driven architecture – EDA) es un patrón de diseño construido alrededor de la producción, detección y reacción a los eventos que tienen lugar. Es un paradigma de diseño normalizado para contextos dinámicos, asíncronos y orientados a procesos. Esta arquitectura permite un enganche mínimo, lo que la convierte en una buena opción para arquitecturas modernas de aplicaciones distribuidas.

La Arquitectura Dirigida por Eventos se centra en la generación y entrega de notificaciones de eventos. Este concepto define arquitecturas flexibles, en las cuales los elementos que generan las notificaciones de eventos no necesitan los componentes del receptor. Sumado a esto, una arquitectura dirigida por eventos no tiene un tiempo de respuesta determinístico para procesar eventos de input, pero es mucho más rápida adaptándose a los cambios. Este paradigma convierte en una realidad la creación de arquitecturas con respuesta en tiempo real. Las notificaciones de eventos implican modificaciones en el estado actual del sistema. Las notificaciones se pueden disparar bien por fuentes externas como pueden ser inputs de usuarios, o necesidades del mercado. Sin embargo, también hay notificaciones de eventos internas, como el envío de información por el pipeline de la cadena de trabajo, multidifusión de parámetros para procesos heterogéneos, disparadores internos para ciertos servicios y generación de outputs. Al final, los eventos se pueden entender como una especie de mensajes entre distintos módulos del sistema, conteniendo información relevante acerca del funcionamiento general y particular del sistema y sus servicios.

Una arquitectura guiada por eventos utiliza eventos para dispararse y comunicarse entre servicios desacoplados y es común en aplicaciones modernas construidas con microservicios. Un evento es un cambio de estado, o una actualización, como un elemento cuando se coloca en un carrito de la compra en un e-commerce. Los eventos pueden llevar el estado (el elemento comprado, su precio y la dirección de entrega) o pueden ser identificadores (una notificación de que el pedido se ha enviado).

Una arquitectura guiada por eventos consiste principalmente de creadores de eventos, gestores de eventos y consumidores de eventos. El creador de eventos, la fuente del evento, solo sabe que el evento ha tenido lugar y transmite una señal para indicarlo. Un gestor de eventos funciona a modo de gestor intermedio de eventos. Los consumidores son entidades que precisar conocer que el evento ha tenido lugar y normalmente se suscriben a algún tipo de gestor de eventos.

Para entenderlo mejor, veamos un buen ejemplo: un servicio online de alojamiento donde los creadores de eventos (los propietarios de los alojamientos) transmiten la disponibilidad de un alojamiento al gestor de eventos (la plataforma online), que agregaría esta transmisión, y los consumidores (la gente que está buscando alojamiento) se puede suscribir a la lista de mailing de la plataforma, que les enviaría notificaciones acerca de novedades relevantes.

El beneficio de una arquitectura guiada por eventos es que permite a un gran número de creadores y consumidores intercambiar información de estado y respuesta prácticamente en tiempo real.

Son muchas las empresas famosas que trabajan con esta arquitectura: Uber, Deliveroo, Monzo Bank o Centrica, entre otras. Todas ellas comparten un uso de información en tiempo real proporcionada por los usuarios, redes IoT y movimientos en el mercado.

 

Modelos de Arquitectura Guiada por Eventos

Una arquitectura guiada por eventos puede estar basada tanto en un modelo pub/sub como en un modelo event stream.

 

Modelo sub/sub
Infraestructura basada en suscripciones a un event stream, que realiza un seguimiento de las suscripciones. Con este modelo, cada vez que sucede un evento, o se publica, se envía a los suscriptores que necesitan ser informados.

Modelo Event streaming
Con un modelo event streaming, los eventos se escriben en un registro. Los consumidores de eventos no se suscriben a un event stream. En vez de esto, pueden leer cualquier parte del stream y unirse en cualquier momento.

 

Beneficios de la Arquitectura Guiada por Eventos

  • Arquitectura dirigida por eventos es asíncrona sin bloqueo. Esto permite a los recursos pasar libremente a la siguiente tarea una vez su unidad de trabajo ha sido terminada, sin preocuparse de lo que suceda antes o después.
  • Los servicios no necesitan saber o depender de otros servicios. Cuando se usan eventos, los servicios operan independientemente, sin conocimiento de los otros servicios, incluyendo los detalles de su implementación y su protocolo de transporte.
  • Los servicios bajo un modelo de eventos se pueden actualizar, testear y desplegar independientemente y de forma más fácil.
  • Ya que los servicios en una arquitectura guiada por eventos están desacoplados, y ya que usualmente solo realizan una tarea, es mucho más fácil buscar cuellos de botella en un servicio específico y escalar dicho servicio.
  • Una arquitectura guiada por eventos con una cola puede recuperar trabajo perdido al “repetir” eventos del pasado. Esto puede ser valioso para prevenir la pérdida de información cuando un consumidor necesitar recuperarla.
  • Este patrón adquiere un rendimiento muy alto a través de sus capacidades asíncronas, la capacidad de ejecutar operaciones desacopladas asíncronas en paralelo supera el coste de poner y quitar mensajes de una cola.
  • La escalabilidad se logra de forma natural en este patrón mediante procesadores de eventos altamente independientes y desacoplados. Cada procesador de eventos puede escalar por separado, permitiendo una escalabilidad fina.
  • La conciencia situacional en tiempo real significa que las decisiones de negocios, ya sean manuales o automatizadas, se pueden hacer usando toda la información disponible que refleja el estado actual de los sistemas.

Conclusión: arquitectura dirigida por eventos

Hoy en día, muchas empresas emergentes utilizan modelos de negocio basados en la Economía Bajo Demanda. Además de esto, la adquisición de información se está volviendo masiva, gracias a las modas tecnológicas y sociológicas como son las redes sociales y el IoT. La arquitectura guiada por eventos es el paradigma natural para usar esta información en tiempo real y diseñar sistemas flexibles capaces de adaptarse a los cambios.

Sin embargo, el patrón de arquitectura dirigida por eventos es un patrón relativamente complicado de implementar, principalmente debido a su naturaleza de distribución asíncrona. Al implementar este patrón, debes hacer frente a varios factores de la arquitectura distribuida, como la disponibilidad remota de procesos, falta de capacidad de respuesta y la lógica de reconexión de un broker en la eventualidad de que un broker o mediador falle.

Una consideración a tener en cuenta al elegir este patrón arquitectónico es la falta de transacciones atómicas para un solo proceso de negocio. Debido a que los componentes de un procesador de eventos están altamente desacoplados y distribuidos, es muy difícil mantener una unidad de trabajo transaccional a través de los mismos. Por esta razón, al diseñar tu aplicación usando este patrón, debes pensar constantemente acerca de qué eventos pueden o no pueden ejecutarse independientemente, y planear la granularidad de tus procesadores de eventos de forma consecuente. Si ves que necesitas dividir una unidad de trabajo a través de los procesadores de eventos – es decir, si estás usando procesadores separados para lo que debería ser una transacción indivisible – probablemente este patrón no sea el adecuado para tu aplicación.

Y si tienes interés en saber más acerca de la arquitectura guiada por eventos, te recomendamos encarecidamente que leas este libro de Hugh Taylor “Event-Driven Architecture: How SOA Enables the Real-Time Enterprise: How SOA Enables the Real-Time Enterprise”.