Orion Protocol

Arquitectura Basada en Eventos: Guía Práctica y Tipos de Topologías

La arquitectura basada en eventos (EDA, por sus siglas en inglés, Event-Driven Architecture) es un estilo de arquitectura de software que utiliza eventos para desacoplar y desencadenar la comunicación entre los distintos servicios y componentes de un sistema. En este contexto, un evento es un cambio significativo en el estado del sistema, como una nueva orden de compra, el registro de un usuario o una actualización de un producto. A diferencia de las arquitecturas síncronas tradicionales, la EDA se basa en la comunicación asíncrona, permitiendo flujos de trabajo flexibles y altamente escalables.

Este enfoque arquitectónico no es exclusivo de un solo sistema; puede utilizarse de forma aislada para resolver problemas específicos o combinarse con otros estilos de arquitectura, como la arquitectura de microservicios. Su principal ventaja es la capacidad de crear sistemas altamente reactivos y resilientes que responden a cambios de estado en tiempo real, lo cual es fundamental en aplicaciones modernas como el Internet de las Cosas (IoT), plataformas de comercio electrónico y sistemas de análisis de datos.

En la arquitectura basada en eventos existen dos topologías principales para orquestar la comunicación:

1. Topología Broker

   La topología Broker es una de las implementaciones más comunes de la arquitectura basada en eventos. En este modelo, la comunicación se maneja a través de un intermediario o broker de mensajes. Los productores de eventos (también llamados publishers o event producers) envían mensajes al broker sin saber quién los consumirá. A su vez, los procesadores de eventos (subscribers o event consumers) se suscriben a los tipos de eventos que les interesan.

   Este enfoque crea un sistema altamente desacoplado, ya que los componentes no necesitan conocer la existencia de otros. El flujo es secuencial y directo, lo que resulta en un alto rendimiento y baja latencia. Es ideal para flujos de procesamiento simples que no requieren una orquestación centralizada.

   Componentes clave en la topología Broker:

   • Productor de eventos: Es el componente que genera un evento inicial. Lo envía a una cola de mensajes a través del broker de eventos.
   • Broker de eventos: Actúa como un mediador pasivo. Recibe los eventos y los enruta a los procesadores de eventos que se han suscrito a ese tipo de evento. No tiene conocimiento del flujo de trabajo, solo distribuye los mensajes. Ejemplos de brokers de eventos son Apache Kafka, RabbitMQ o Amazon SQS.
   • Procesador de eventos: Componente que recibe y procesa el evento. Cuando lo recibe, inicia su propio flujo de trabajo interno. Un solo evento puede ser procesado por uno o varios procesadores de forma simultánea, lo que permite la creación de funcionalidades diversas y paralelas.

   Ventajas de la topología Broker:

   • Desacoplamiento: Los componentes son completamente independientes. Un cambio en un servicio no afecta a los demás.
   • Escalabilidad: Es posible escalar cada componente de manera individual. Si el número de eventos aumenta, se pueden añadir más procesadores de eventos sin modificar el resto del sistema.
   • Rendimiento: El flujo no tiene un intermediario que lo orqueste, permitiendo que cada componente aproveche su poder de procesamiento.
   • Extensibilidad: Es muy fácil añadir nuevas funcionalidades. Simplemente se crea un nuevo procesador de eventos y se suscribe al tipo de evento deseado.

   Desventajas de la topología Broker:

   • Manejo de errores complejo: No hay un control central sobre el flujo de trabajo, lo que dificulta la detección de errores o la pérdida de información.
   • Dificultad de depuración: Sin una figura central que orqueste, es complicado trazar la ruta de un evento a través de múltiples servicios.

   

2. Topología Mediador

   A diferencia del Broker, la topología Mediador tiene una figura central activa que se encarga de controlar y orquestar todo el flujo de trabajo. Un mediador recibe los eventos del productor, toma decisiones basadas en el tipo de evento y coordina a los procesadores de eventos adecuados para que realicen su tarea.

   En este modelo, el mediador actúa como un orquestador. No solo distribuye los mensajes, sino que conoce la secuencia de pasos que se deben seguir.

   Funcionamiento de la topología Mediador:

   1. Un productor de eventos genera un evento inicial que se añade a una cola de mensajes.
   2. El mediador monitorea la cola de mensajes.
   3. Dependiendo del evento inicial, el mediador coordina y distribuye el evento a los procesadores de eventos adecuados.
   4. Los procesadores de eventos ejecutan su tarea.
   5. Una vez finalizado, los procesadores de eventos notifican al mediador.

   Este proceso permite monitorear de cerca todo el flujo de trabajo y asegurar su correcta ejecución.

   

   Ventajas de la topología Mediador:

   • Control del flujo: El mediador tiene una visión completa del flujo de trabajo, facilitando la auditoría y el control.
   • Manejo de errores mejorado: Al tener un punto central de control, se pueden implementar mecanismos de reintento o compensación ante fallos.
   • Recuperabilidad: El monitoreo constante permite una fácil recuperación del sistema en caso de fallos.
   • Consistencia de los datos: Se puede asegurar que los datos fluyen de forma correcta y que se completan todas las tareas necesarias.

   Desventajas de la topología Mediador:

   • Acoplamiento entre procesadores: Los procesadores están acoplados al mediador, lo que reduce la independencia.
   • Menor escalabilidad: El mediador puede convertirse en un punto único de fallo o un cuello de botella, limitando la escalabilidad del sistema.
   • Menor tolerancia a fallos: Un fallo en el mediador detiene todo el flujo de trabajo.

¿Qué pasa con la comunicación síncrona?

Aunque la EDA es intrínsecamente asíncrona, a veces se necesita una respuesta inmediata. Para esos casos, se puede implementar un patrón de comunicación “Request-Reply” que simula una comunicación pseudosíncrona.

Este patrón funciona de la siguiente manera:

1. Un productor de eventos genera un mensaje de “solicitud” y lo envía a una cola de mensajes para que el consumidor lo procese.
2. Al mismo tiempo, el productor se queda en un estado de espera, monitoreando una cola de respuesta.
3. El consumidor de eventos recibe el mensaje, lo procesa y genera un mensaje de “respuesta”.
4. La respuesta se envía a la cola de respuesta.
5. El productor de eventos recibe y procesa la respuesta, completando así el ciclo.

Este método permite mantener los beneficios de la arquitectura basada en eventos mientras se manejan requerimientos de comunicación síncrona cuando son estrictamente necesarios.

Cuándo usar y cuándo no la Arquitectura Basada en Eventos

Utiliza la Arquitectura Basada en Eventos cuando:

• Necesitas que los componentes de tu sistema sean desacoplados y escalables de forma independiente.
• Los sistemas requieren una alta reactividad y deben responder a cambios de estado en tiempo real (ej. IoT, análisis de datos, streaming).
• El sistema maneja un flujo de trabajo complejo que puede ser ejecutado en paralelo (por ejemplo, al subir una imagen se pueden disparar eventos para redimensionar, etiquetar y analizar su contenido al mismo tiempo).
• Buscas aumentar la resiliencia del sistema.

Evita la Arquitectura Basada en Eventos cuando:

• Las transacciones requieren una comunicación síncrona y una respuesta inmediata, y el patrón Request-Reply no es una solución viable.
• El flujo de trabajo es simple y lineal, y no justifica la complejidad de añadir un broker o mediador.
• Los procesos requieren la ejecución de múltiples pasos de forma muy estricta y secuencial, donde cualquier fallo en un paso detendría toda la cadena de forma crítica.
• Estás construyendo una aplicación simple con un solo monolito donde el desacoplamiento no es una prioridad.

En conclusión, la arquitectura basada en eventos ofrece una manera poderosa y flexible de construir sistemas resilientes y escalables. La elección entre las topologías Broker y Mediador dependerá de la complejidad de tu flujo de trabajo y del nivel de control que necesites sobre la orquestación de tus eventos.