La arquitectura basada en eventos es un modelo de integración creado en torno a la publicación, la captura, el procesamiento y el almacenamiento (o la persistencia) de eventos. Cuando una aplicación o servicio realiza una acción o sufre un cambio que otra aplicación o servicio puede 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 cambio.

La arquitectura basada en eventos permite un acoplamiento dinámico entre las aplicaciones y los servicios conectados, que pueden comunicarse entre sí mediante la publicación y el consumo de eventos sin otra información que el formato del evento. Este modelo ofrece ventajas significativas frente a la arquitectura de solicitud/respuesta (o modelo de integración), donde una aplicación o servicio debe solicitar información específica de otra aplicación o servicio que espera la solicitud.

La arquitectura basada en eventos maximiza el potencial de las aplicaciones nativas en cloud y permite utilizar potentes tecnologías de aplicaciones, como el análisis en tiempo real y el soporte de decisiones.

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

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

En un ejemplo simple, un servicio bancario puede transmitir un evento de "depósito", que otro servicio en el banco consumirá y al que responderá escribiendo un depósito en el extracto del cliente. No obstante, las integraciones basadas en eventos también pueden desencadenar respuestas en tiempo real basadas en análisis complejos de grandes volúmenes de datos, por ejemplo, cuando el "evento" de un cliente que pulsa 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 varias clases de mensajes publicados por los generadores de eventos. Cuando un generador de eventos publica un evento, el mensaje se envía directamente a todos los suscriptores que desean consumirlo.

Normalmente, un intermediario de mensajes maneja la transmisión de mensajes de eventos entre los publicadores y los suscriptores. El intermediario recibe cada mensaje de evento, lo traduce si es necesario, mantiene su orden relativo a otros mensajes, hace que esté disponible para el consumo de los suscriptores y, a continuación, lo elimina una vez que se ha consumido (para que no se pueda volver a consumir).

Transmisión de eventos

En el modelo de transmisión de eventos, los generadores de eventos publican secuencias de eventos en un intermediario. Los consumidores de eventos se suscriben a las secuencias, pero en lugar de recibir y consumir cada evento cuando se publica, los consumidores pueden entrar en cada secuencia en cualquier punto y consumir solo los eventos que deseen consumir. La diferencia clave aquí es que el intermediario retiene los eventos incluso después de que los consumidores los hayan recibido.

Una plataforma de transmisión de datos, por ejemplo, Apache Kafka, gestiona el registro y la transmisión de ingentes volúmenes de eventos con un caudal muy alto (literalmente, billones de registros de eventos al día, en tiempo real, sin retrasos en el rendimiento). Una plataforma de transmisión proporciona algunas características que un intermediario de mensajes no ofrece:

• Persistencia de eventos: como los consumidores pueden consumir eventos en cualquier momento una vez publicados, los registros de transmisión de eventos son persistentes (se mantienen una cantidad de tiempo configurable, desde fracciones de segundo hasta permanentemente). Esto permite a las aplicaciones de secuencias de eventos procesar datos históricos, así como datos en tiempo real.
  
  
• Procesamiento de eventos complejo: al igual que la mensajería de eventos, la transmisión de eventos se puede utilizar para el procesamiento de eventos simple, donde cada evento publicado desencadena la transmisión y el procesamiento por parte de uno o varios consumidores. No obstante, también se puede usar para el procesamiento de eventos complejo, donde los consumidores de eventos procesan series completas de eventos y realizan acciones basadas en el resultado.

Comparada con la arquitectura de aplicaciones de solicitud/respuesta, la arquitectura basada en eventos ofrece varias ventajas y oportunidades para los desarrolladores y las organizaciones.

Potentes análisis y respuestas en tiempo real: la transmisión de eventos habilita aplicaciones que responden a situaciones empresariales cambiantes a medida que ocurren y, a continuación, realizan predicciones y toman decisiones basadas en todos los datos actuales e históricos disponibles en tiempo real. Esto ofrece ventajas en muchas áreas, desde el procesamiento de secuencias de datos generadas por una gran variedad de dispositivos de IoT, hasta la predicción y la eliminación de amenazas seguridad sobre la marcha, pasando por la automatización de cadenas de suministro para garantizar una eficiencia óptima.

Tolerancia a errores, escalabilidad, mantenimiento simplificado, versatilidad y otras ventajas del acoplamiento dinámico: las aplicaciones y los componentes en un artículo basado en eventos no dependen de la disponibilidad de los demás; se pueden actualizar, probar y desplegar de manera independiente sin interrumpir el servicio y, cuando un componente cae, se puede poner en línea una copia de seguridad. La persistencia de eventos permite la "reproducción" de eventos pasados, lo que puede ayudar a recuperar datos o funcionalidad si hay una parada del consumidor de eventos. Los componentes se pueden escalar fácilmente de manera independiente unos de otros a través de la red, y los desarrolladores pueden revisar o enriquecer las aplicaciones y los sistemas añadiendo y eliminando generadores y consumidores de eventos.

Mensajería asíncrona: la arquitectura basada en eventos permite que los componentes se comuniquen de forma asíncrona: los generadores publican mensajes de eventos según su propia planificación, sin esperar a que los consumidores los reciban (o incluso sin saber si los consumidores los han recibido). Además de simplificar la integración, esto mejora la experiencia de la aplicación para los usuarios. Un usuario que realiza una tarea en un componente puede pasar a la siguiente tarea sin esperar, independientemente de las integraciones en sentido descendente entre ese componente y otros componentes en el sistema.

En los microservicios (una arquitectura fundacional de aplicaciones nativas en el cloud), las aplicaciones se ensamblan a partir de servicios débilmente acoplados y de despliegue independiente. Las principales ventajas de los microservicios son esencialmente las ventajas del acoplamiento débil: facilidad de mantenimiento, flexibilidad de despliegue, escalabilidad independiente y tolerancia a errores.

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