En el panorama dinámico del desarrollo Agile y LEAN, los patrones arquitectónicos evolucionan continuamente para ofrecer soluciones adaptables. Raramente construimos sistemas completos; en su lugar, utilizamos frameworks, bibliotecas y servicios de terceros para ser más eficientes.
Buscamos patrones de arquitectura que fomenten la flexibilidad, adaptabilidad, experimentación, escalabilidad y seguridad en nuestro dominio específico.
En este artículo, profundizaré en las Arquitecturas Orientadas a Eventos (EDAs), explorando los sistemas mediadores, los tipos de eventos y los desafíos que he encontrado a lo largo de mi carrera.
Aunque sus raíces pueden rastrearse de alguna forma hasta la década de 1950, las EDAs han evolucionado para ayudar a los equipos Agile y LEAN a hacer su trabajo.
¿Qué es un Evento?
Comencemos con el protagonista del espectáculo: el Evento.
Un Evento es un hecho inmutable. Algo que ha sucedido, no puede deshacerse ni cambiarse.
Los eventos ocurren continuamente en nuestras vidas, desde el momento en que nos despertamos, nos preparamos para el día, comemos, pagamos el autobús, y así sucesivamente. Los eventos llenan nuestras vidas.
Tenemos la opción de escuchar, registrar y decidir qué hacer con la información que obtenemos de estos eventos. Alternativamente, podemos optar por no compartir o no preocuparnos por ciertos eventos.
Para mí, esta es la esencia de las Arquitecturas Orientadas a Eventos y la razón por la que pueden ser un patrón extremadamente útil para muchos casos de uso. ¡Profundicemos!
¿Qué son las Arquitecturas Orientadas a Eventos?
Las EDAs son patrones arquitectónicos que se basan en los eventos como su contrato. Están diseñadas para reaccionar a los cambios aprovechando la naturaleza inmutable de los eventos.
Las EDAs típicamente siguen un patrón de publicación/suscripción, donde los servicios publican eventos en un servicio mediador y los suscriptores consumen esos eventos. El servicio publicador no necesita saber quién consume los eventos ni si alguien reacciona a ellos. Este enfoque mejora el desacoplamiento de servicios, ya que el acoplamiento se basa en el contenido del evento.
Uno de los beneficios clave de las EDAs es su capacidad para facilitar la escalabilidad y la adaptabilidad. A medida que aumenta el tráfico del sistema, podemos agregar más consumidores para gestionar los eventos adicionales, y podemos eliminarlos cuando todos los eventos hayan sido consumidos. Esta flexibilidad permite la experimentación y la capacidad de intercambiar servicios continuamente. Al agregar elementos como feature flags y despliegues exponenciales, los equipos pueden ejecutar este proceso varias veces al día y experimentar, reduciendo el riesgo y aumentando su velocidad.
Sin embargo, es importante señalar que las EDAs pueden introducir complejidad debido a su naturaleza distribuida. También pueden resultar en mensajes duplicados y consistencia eventual. Los suscriptores necesitan considerar el orden de los eventos y asegurarse de que sean idempotentes, lo que significa que pueden procesar el mismo evento múltiples veces sin generar resultados diferentes.
Las EDAs son principalmente relevantes para procesos asíncronos como auditoría, procesamiento de datos y operaciones de backend. Son útiles para sistemas con picos repentinos de tráfico. Sin embargo, es importante considerar la latencia adicional que introduce esta arquitectura.
En general, las EDAs ofrecen ventajas en términos de desacoplamiento, escalabilidad, adaptabilidad y experimentación. Sin embargo, requieren una consideración cuidadosa de la complejidad, los mensajes duplicados y la consistencia eventual…
Sistemas Mediadores
En las EDAs, los publicadores y suscriptores requieren un sistema escalable que actue como mediador para garantizar que los eventos se entreguen a los servicios interesados. Esta seccion explora los diversos sistemas mediadores que se encuentran comunmente en estas arquitecturas.
Message Brokers y Event Buses
Con diferencia, los componentes intermediarios más conocidos en las EDAs son los message brokers y los event buses. Todos los principales proveedores de nube ofrecen servicios que gestionan eficientemente el proceso de mediación. He tenido la oportunidad de aprender y explorar AWS, que ha hecho un excelente trabajo con su servicio AWS EventBridge y su integración con otros servicios y proveedores externos.
A la hora de decidir qué servicio utilizar, depende en última instancia de tu caso de uso específico. Si ya dependes de AWS, EventBridge podría ser exactamente lo que necesitas. Sin embargo, si utilizas otro proveedor de nube, vale la pena explorar sus ofertas, ya que también podrían cumplir con tus requisitos.
Ahora, profundicemos en el tema. ¿Qué hacen exactamente estos sistemas intermediarios?
En el modelo Pub/Mediador/Sub, los publicadores envían sus eventos al mediador y los suscriptores se suscriben a los eventos que les interesan. Estos sistemas mediadores proporcionan funcionalidades como enrutamiento, transformación, validación, gestión de esquemas/catálogos de eventos, archivado y más, dependiendo de la solución elegida.
En el pasado, los message brokers se veían a menudo como sistemas persistentes similares a bases de datos, mientras que los event buses eran sistemas más basados en memoria que descartaban los eventos después de un cierto periodo. Sin embargo, la línea entre brokers y buses se ha vuelto cada vez más difusa. Por ejemplo, AWS EventBridge, que es un event bus, ofrece funciones para archivar y reproducir mensajes, mientras que los message brokers pueden proporcionar colas efímeras.
Colas y Streams
Aunque no se consideran mediadores por sí solos, las colas y los streams son componentes que funcionan muy bien en las EDAs. Pueden ayudarte a mejorar, potenciar y/o simplificar soluciones.
Veamos una descripción general rápida de las Colas y los Streams.
Colas
Las colas son excelentes compañeras de los Event Buses y los Message Brokers. Proporcionan una forma sencilla de almacenar y transmitir eventos entre componentes, asegurando que no se pierdan datos y dando al consumidor control sobre la velocidad de procesamiento de los eventos.
Al igual que las colas en la vida real, existen diferentes tipos, como colas ordenadas (FIFO, LIFO), colas de prioridad, DLQs, etc.; y necesitarás configurar su periodo de retención, reintentos y demás, pero son sistemas bastante sencillos que simplemente funcionan y hacen lo que prometen.
Son una forma excelente y sencilla de desacoplar sistemas y simplificar la vida de los consumidores.
Streams
Los streams están diseñados para el procesamiento y análisis de datos en tiempo real en sistemas que requieren transferencia y análisis de datos con baja latencia a través de múltiples ventanas temporales.
Aquí tendrás que configurar escritores, lectores y retención. Son útiles si tienes un caso de uso definido donde necesitas realizar un análisis sobre grandes cantidades de datos en constante cambio.
Tipos de Eventos
Ahora que hemos visto el núcleo de las EDAs, profundizaremos en los diferentes tipos de eventos que puedes encontrar.
Existen 4 tipos: Notificación, Transferencia de Estado Transportada por Eventos, Eventos Delta y Eventos de Negocio.
Veamos más de cerca cada uno de estos tipos de eventos.
Eventos de Notificación
Los eventos de notificación se utilizan para informar a las partes interesadas sobre ocurrencias o actualizaciones específicas. Estos eventos están diseñados para ser pequeños, conteniendo solo la información mínima necesaria para reducir el riesgo de romper contratos.
Aquí tienes un ejemplo de cómo puede verse un evento de notificación:
{
"eventName": "PaymentSuccessful",
"details": {
"data": {
"paymentId": "UUID"
}
}
}Los eventos de notificación siguen un modelo pull, permitiendo a los consumidores obtener información adicional de los publicadores según sea necesario. Esto introduce un patrón de callback y añadirá latencia extra al sistema, pero ayuda a evitar problemas de ordenamiento en la mayoría de los casos.
Dado que los eventos de notificación tienen un número limitado de campos, ciertas funcionalidades proporcionadas por los mediadores, como la validación, el enrutamiento y el filtrado, pueden verse reducidas.
Transferencia de Estado Transportada por Eventos
Este tipo de evento puede considerarse el opuesto de los Eventos de Notificación. Incluye tanto los datos del evento como el estado actual del sistema, permitiendo a la parte receptora actualizar su propio estado en consecuencia. Estos eventos son más grandes, ya que incluyen todos los datos disponibles que el publicador tiene sobre el evento/sujeto.
Aquí tienes un ejemplo de este tipo de evento:
{
"eventName": "PaymentSuccessful",
"details": {
"data": {
"paymentId": "UUID",
"paymentType": "Card",
"timestamp": "yyyy-mm-dd hh:mm:ss",
"accountId": "UUID",
"currencyCode": "GBP"
}
}
}Debido a su mayor tamaño e información incrementada, estos eventos conllevan un mayor riesgo de romper contratos, filtrar información de identificación personal (PII) y encontrar problemas con la consistencia eventual y/o el ordenamiento. El acoplamiento en este caso ocurre en el contrato, y sigue un modelo push donde el estado se envía a los consumidores.
Adicionalmente, estos eventos proporcionan más opciones para agregar reglas de filtrado y enrutamiento en el servicio mediador. Esto elimina la necesidad de que los consumidores gestionen dicha lógica y mejora enormemente la capacidad de dirigirse a servicios específicos.
Eventos Delta
Los eventos delta solo contienen los cambios o actualizaciones que han ocurrido desde el ultimo evento, reduciendo la cantidad de datos transmitidos.
Aquí tienes un ejemplo de un evento delta:
{
"eventName": "PaymentUpdated",
"details": {
"data": {
"paymentId": "UUID",
"updatedFields": ["paymentType", "timestamp"],
"updatedValues": ["Credit Card", "yyyy-mm-dd hh:mm:ss"]
}
}
}Los eventos delta pueden ser útiles para identificar cambios y gestionar el ordenamiento de eventos de manera más efectiva. También pueden ser más eficientes que enviar el contenido completo del evento u obtener información de los servicios publicadores.
Eventos de Negocio
Estos eventos son específicos del dominio o contexto de negocio.
Como con todos los sistemas, la realidad te situará entre eventos, y tus eventos tenderán a reducir el contenido a la información que se necesita.
En algunos casos, será útil crear eventos que estén limitados por un dominio de negocio e incluyan campos internos que solo sean importantes para tu dominio.
Aquí tienes un ejemplo de un evento de negocio para un pago exitoso:
{
"eventName": "PaymentSuccessful",
"details": {
"data": {
"paymentId": "UUID",
"accountId": "UUID",
"amount": 100.00,
"currencyCode": "USD",
"timestamp": "yyyy-mm-dd hh:mm:ss",
"transactionId": "UUID",
"paymentMethod": "Credit Card",
"status": "AD345"
}
}
}La mayoría de los eventos de negocio pueden terminar graduándose para convertirse en eventos que otras partes del sistema necesitan. Intenta evitar tener que reemitir eventos e intenta absorber las transformaciones.
Desafíos y Consideraciones
Al decidir aplicar una Arquitectura Orientada a Eventos en tu sistema, hay varios desafíos y consideraciones a tener en cuenta.
En primer lugar, los eventos juegan un papel crucial en el sistema y requieren especial cuidado y atención. Es importante considerar cuidadosamente aspectos como el nombre del evento, su tipo, la marca temporal (inicio, fin, rango…) y la estructura general desde el principio.
La documentación y el versionado de los eventos son esenciales. Las EDAs deben permitir que los eventos evolucionen y cambien con el tiempo, lo cual solo puede lograrse mediante una gobernanza adecuada, documentación y control de versiones.
Aunque las EDAs mejoran la escalabilidad del sistema, también introducen complejidad. Factores como el ordenamiento de mensajes, la entrega, la consistencia eventual y la duplicación deben tenerse en cuenta.
La complejidad operativa también aumentará. La monitorización, la gestión y los procesos operativos necesitan un énfasis adicional.
La resiliencia ante fallos es primordial en una EDA. Medidas como reintentos de mensajes, colas de mensajes fallidos y otros mecanismos deben implementarse para garantizar la recuperación del sistema.
El impacto de las EDAs en el proceso de desarrollo también debe considerarse. Las estrategias de pruebas, despliegue y depuración necesitan adaptarse en consecuencia.
Las preocupaciones de seguridad y datos son de suma importancia, particularmente cuando se manejan datos sensibles o retención de datos a largo plazo. El cumplimiento con marcos regulatorios como el RGPD debe abordarse.
Por último, el impacto organizativo de las EDAs necesita evaluarse. La organización del equipo, la gestión y las estrategias de comunicación deben alinearse con los requisitos de un sistema basado en EDAs.
Conclusión
En este documento, hemos visto qué son los eventos, las arquitecturas orientadas a eventos, los sistemas mediadores, los tipos de eventos que puedes encontrar en tu sistema, para terminar con algunos desafíos y consideraciones.
¿Deberías usar una EDA en tu sistema? La respuesta es: depende. Recomendaría no depender únicamente de las EDAs, sino usarlas en combinación con otras arquitecturas.
Las EDAs son un patrón poderoso para aumentar la escalabilidad y flexibilidad de tu sistema, pero también traen consigo muchos desafíos y consideraciones que deben tenerse en cuenta.