La arquitectura basada en eventos es un modelo de integración creado alrededor de la publicación, captura, procesamiento y almacenamiento (o persistencia) de eventos. Cuando una aplicación o servicio realiza una acción o sufre un cambio que otra aplicación o servicio podría querer conocer, publica un evento (un registro de esa acción o cambio) que otra aplicación o servicio puede consumir y procesar para realizar acciones a su vez.

La arquitectura basada en eventos permite un acoplamiento flexible entre aplicaciones y servicios conectados, pueden comunicarse entre sí mediante la publicación y el consumo de eventos sin saber nada entre ellos, excepto el formato del evento. Este modelo ofrece ventajas significativas sobre una arquitectura de solicitud/respuesta (o modelo de integración), en la que una aplicación o servicio debe solicitar información específica de otra aplicación o servicio específico que está esperando la solicitud específica.

La arquitectura basada en eventos maximiza el potencial de las aplicaciones nativas en la nube y habilita potentes tecnologías de aplicaciones, como analítica en tiempo real y soporte de decisiones.

En una arquitectura basada en eventos, las aplicaciones actúan como productores de eventos o consumidores de eventos (y a menudo como ambos).

Un productor de eventos transmite un evento, en forma de mensaje, a un broker o alguna otra forma de router de eventos, donde el orden cronológico del evento se mantiene en relación con otros eventos. Un consumidor de eventos ingiere el mensaje, en tiempo real (cuando ocurre) o en cualquier otro momento que desee, y procesa el mensaje para desencadenar otra acción, flujo de trabajo o evento propio.

En un ejemplo simple, un servicio bancario podría transmitir un evento de "depósito", que otro servicio en el banco consumiría y respondería al escribir un depósito en el extracto del cliente. Pero las integraciones basadas en eventos también pueden desencadenar respuestas en tiempo real basadas en análisis complejos de grandes volúmenes de datos, como cuando el "evento" de un cliente que hace clic en un producto en un sitio de comercio electrónico genera recomendaciones instantáneas de productos basadas en las compras de otros clientes.

Hay dos modelos básicos para transmitir eventos en una arquitectura basada en eventos

Mensajería de eventos o publicación/suscripción

En el modelo de mensajería de eventos o publicación/suscripción, los consumidores de eventos se suscriben a una clase o clases de mensajes publicados por los productores de eventos. Cuando un productor de eventos publica un evento, el mensaje se envía directamente a todos los suscriptores que desean consumirlo.

Normalmente, un message broker maneja la transmisión de mensajes de eventos entre editores y suscriptores. El broker recibe cada mensaje de evento, lo traduce si es necesario, mantiene su orden en relación con otros mensajes, los pone a disposición de los suscriptores para su consumo y luego los borra una vez que se consumen (para que no se puedan volver a consumir).

Streaming de eventos

En el modelo de streaming de eventos, los productores de eventos publican transmisiones de eventos a un broker. Los consumidores de eventos se suscriben a los flujos, pero en lugar de recibir y consumir cada evento a medida que se publica, los consumidores pueden ingresar a cada flujo en cualquier momento y consumir solo los eventos que desean consumir. La diferencia clave aquí es que el broker retiene los eventos incluso después de que los consumidores los hayan recibido.

Una plataforma de streaming de datos, como Apache Kafka, gestiona el registro y la transmisión de enormes volúmenes de eventos con un rendimiento muy alto (literalmente billones de registros de eventos por día, en tiempo real, sin retrasos en el rendimiento). Una plataforma de streaming ofrece ciertas características que un broker de mensajes no tiene:

• Persistencia de eventos: debido a que los consumidores pueden consumir eventos en cualquier momento después de su publicación, los registros de streaming de eventos son persistentes: se mantienen durante un período de tiempo configurable, desde fracciones de segundo hasta para siempre. Esto permite que las aplicaciones de flujo de eventos procesen datos históricos, así como datos en tiempo real.
  
  
• Procesamiento de eventos complejos: al igual que la mensajería de eventos, el streaming de eventos se puede utilizar para un procesamiento simple de eventos, en el que cada evento publicado desencadena la transmisión y el procesamiento por parte de uno o más consumidores específicos. Pero también se puede utilizar para el procesamiento de eventos complejos, en los que los consumidores de eventos procesan una serie completa de eventos y realizan acciones en función del resultado.

En comparación con la arquitectura de aplicación de solicitud/respuesta, la arquitectura basada en eventos ofrece varias ventajas y oportunidades para desarrolladores y organizaciones:

Potente respuesta y analítica en tiempo real: el streaming de eventos habilita aplicaciones que responden a situaciones empresariales cambiantes a medida que ocurren y hacen predicciones y decisiones basadas en todos los datos actuales e históricos disponibles en tiempo real. Esto ofrece beneficios en muchas áreas, desde el procesamiento de flujos de datos generados por una miríada de dispositivos de IoT, la predicción y eliminación de amenazas de seguridad sobre la marcha, hasta la automatización de las cadenas de suministro para brindar una eficiencia óptima.

Tolerancia a fallas, escalabilidad, mantenimiento simplificado, versatilidad y otros beneficios del acoplamiento flexible: las aplicaciones y los componentes de un artículo basado en eventos no dependen de la disponibilidad de cada uno. Se pueden actualizar, probar e implementar de forma independiente sin interrumpir el servicio, y cuando un componente deja de funcionar, se puede poner en línea una copia de seguridad. La persistencia de eventos permite la "reproducción" de eventos pasados, lo que ayuda a recuperar datos o funcionalidades si hay una interrupción del consumidor de eventos. Los componentes se pueden escalar fácilmente e independientemente entre sí a través de la red, y los desarrolladores pueden revisar o enriquecer aplicaciones y sistemas al agregar y eliminar productores y consumidores de eventos.

Mensajería asincrónica: la arquitectura basada en eventos permite que los componentes se comuniquen de forma asincrónica. Los productores publican mensajes de eventos, en su propio horario, sin esperar a que los consumidores los reciban (o incluso saber si los consumidores los recibieron). Además de simplificar la integración, esto mejora la experiencia de la aplicación para los usuarios. Un usuario que completa una tarea en un componente puede pasar a la siguiente tarea sin esperar, independientemente de las integraciones posteriores entre ese componente y otros en el sistema.

En los microservicios, una arquitectura de aplicación nativa en la nube fundamental, las aplicaciones se ensamblan a partir de servicios implementables de forma independiente y poco acoplados. Los principales beneficios de los microservicios son esencialmente los beneficios del acoplamiento flexible: facilidad de mantenimiento, flexibilidad de implementación, escalabilidad independiente y tolerancia a fallas.

No es sorprendente que la arquitectura basada en eventos se considere una práctica recomendada para las implementaciones de microservicios. Los microservicios pueden comunicarse entre sí mediante API REST. No obstante, REST, un modelo de integración de solicitud/ respuesta, reduce muchos de los beneficios de la arquitectura de microservicios débilmente acoplados al forzar una integración síncrona y estrechamente acoplada entre los microservicios.