Una Arquitectura Basada en Eventos (Event-Driven Architecture, EDA) se caracteriza por aplicaciones compuestas de componentes que están acoplados de forma flexible, interactuando en respuesta a eventos desencadenados por acciones o cambios en el sistema.
Este enfoque de acoplamiento flexible no solo mejora la modularidad y escalabilidad de las aplicaciones, sino que también ofrece varios beneficios adicionales, como una mayor capacidad de respuesta, resiliencia y facilidad para integrar nuevos componentes en sistemas distribuidos.
Beneficios de una Arquitectura basada en Eventos (EDA)
Escalabilidad: Uno de los principales beneficios de una EDA es su escalabilidad, que permite al sistema manejar grandes volúmenes de eventos distribuyendo las cargas de trabajo entre múltiples servicios. Además, las EDA son capaces de procesar eventos en tiempo real, lo que permite a los sistemas responder de manera inmediata a los cambios. Esta capacidad es especialmente útil en casos como la detección de fraudes, aplicaciones de IoT, entre otros.
Resiliencia: Otro beneficio significativo es la resiliencia ante fallas. Las arquitecturas basadas en eventos pueden implementar reintentos automáticos para facilitar la recuperación de errores, asegurando que el sistema continúe funcionando incluso si algunos componentes fallan o no responden.
Flexibilidad: La flexibilidad de las EDA permite su adaptación a una amplia variedad de casos de uso, lo que las hace ideales para sistemas complejos y en constante evolución que requieren actualizaciones y cambios frecuentes
Conceptos claves en una Arquitectura basada en Eventos (EDA)
¿Que son los eventos?
Un evento se refiere a cualquier ocurrencia o cambio de estado dentro de un sistema o aplicación que puede requerir procesamiento o respuesta por parte de sus componentes. Esto puede incluir acciones del usuario, notificaciones, actualizaciones, entre otros.
Ejemplo de evento: un evento es un registro de una acción que ha ocurrido. Los eventos abarcan una amplia gama de situaciones, como un usuario que hace clic en el botón de pago en un sitio de compras, lo que desencadena el proceso de compra; un trabajador del almacén que escanea un artículo, lo que actualiza el inventario en el catálogo; o alguien que carga una imagen en una aplicación, provocando que la imagen se procese y almacene.
En términos generales, los eventos representan cualquier cambio de estado en el sistema y suelen estar representados como mensajes que contienen metadatos sobre el evento, como su tipo, hora, ubicación, entre otros detalles relevantes. En una Arquitectura Orientada a Eventos, los eventos son el catalizador fundamental que permite al sistema reaccionar y responder a los cambios en tiempo real.
Productor de evento: Es cualquier componente que genera un evento, lo que puede incluir desde interfaces de usuario hasta sistemas backend.
Consumidor de evento: Son componentes que responden a estos eventos; pueden ser funciones, microservicios u otros tipos de procesos.
Enrutadores o intermediarios de eventos (Brokers): son los sistemas responsables de gestionar el flujo de eventos entre productores y consumidores, asegurando la entrega confiable de los eventos y manteniendo el orden adecuado cuando sea necesario.
Diagrama de flujo en una Arquitectura basada en Eventos
El diagrama de flujo ilustra los conceptos de productores, enrutadores, y consumidores de eventos. El proceso comienza con la generación de un evento a partir de una condición de activación específica; en este ejemplo, el evento se desencadena cuando un cliente realiza un pedido en el sitio web «Retail Website». La acción de realizar el pedido es lo que genera el evento.
A continuación, el evento es dirigido al enrutador correspondiente, que sigue reglas predefinidas para su procesamiento. El enrutador se encarga de ingerir, filtrar y distribuir los eventos a los consumidores adecuados. Es decir, los enrutadores de eventos proporcionan los mecanismos necesarios para gestionar el flujo de eventos dentro de un sistema, conectando las fuentes de eventos con los diversos componentes del backend. Una vez que el evento ha sido procesado por el enrutador, puede ser recibido por cualquier consumidor de eventos que lo requiera.
Los consumidores de eventos pueden procesar un evento, y varios consumidores pueden actuar sobre el mismo evento simultáneamente. En este ejemplo, un sistema financiero procesa un nuevo pedido para verificar y recibir el pago; un sistema de gestión de almacenes actualiza el inventario y prepara el pedido para su envío; y, además, un sistema de notificación informa al cliente enviándole un recibo y la confirmación del pedido. Como se puede observar en este escenario, múltiples componentes colaboran para procesar los eventos, y el procesamiento asíncrono permite aumentar tanto la velocidad como la flexibilidad del sistema en su conjunto.
Si otros eventos necesitan algunos o todos los componentes, pueden escalar individualmente y reaccionar según sea necesario, como otros compradores que revisan el inventario, procesan una devolución o buscan su historial de pedidos.
Espero que esta introducción te haya permitido vislumbrar cómo este enfoque arquitectónico puede ayudarte a construir sistemas más escalables, flexibles y resilientes, capaces de adaptarse a demandas cambiantes y a los requisitos de negocio.
Video: https://www.youtube.com/watch?v=R6tUoxx2gVY
Publicaciones que te pueden interesar:
- Conceptos claves en el diseño y escalabilidad de Software
- Introducción al diseño de una API HTTP
- Cuándo usar SOAP, cuando usar REST?