¿Sabes cómo Amazon o Netflix manejan millones de usuarios al mismo tiempo? El secreto está en la arquitectura basada en eventos. Y hoy te voy a contar todo lo que necesitas saber sobre este enfoque. Además, si te interesa profundizar aún más, hace un tiempo creé el único curso completamente gratuito sobre sistemas distribuidos, que se construyen precisamente sobre este tipo de arquitectura. Así que, si este post te resulta útil, te invito a darle un vistazo:
Índice
1 - Qué es una arquitectura basada en eventos?
Como su nombre bien indica, es una arquitectura en la que la comunicación se basa en eventos. Pero no en la propia aplicación, sino entre aplicaciones.
En este tipo de aplicaciones las acciones que suceden son desencadenadas por un evento que se detecta en el sistema, comúnmente en una aplicación diferente.
El contenido de cada aplicación individual es indiferente a la hora de hablar de la arquitectura global, esto quiere decir que si tienes multiples aplicaciones, una puede utilizar hexagonal, otra Clean arquitectura y el resto ser core driven, así como podemos tener elementos serverless.
Cuando hablamos de arquitecturas de sistemas solemos tener tres principales:
- Arquitectura monolítica, donde todo el código y lógica del sistema está en una sola aplicación.
- Microservicios, donde tenemos aplicaciones pequeñas que se relacionan entre sí.
- Arquitectura basada en eventos, donde técnicamente es una arquitectura de microservicios, pero, comúnmente cuando se habla de microservicios se implica una comunicación directa entre los servicios, mientras que en las arquitecturas basadas en eventos no hay comunicación directa.
NOTA: tengo un post con mas detalles aquí.
En este post vamos a hablar sobre la arquitectura basada en eventos, donde los eventos son mensajes que distintos servicios mandan y otros servicios o aplicaciones reaccionan a dichos eventos.
Por ejemplo en una web de una tienda, cuando alguien hace una compra de un elemento, genera un evento llamado OrderCreated el cual tiene los productos comprados y cuantos.
Una vez el evento se ha creado, el servicio de los pedidos se olvida, es tarea del servicio de inventario el ser capaz de leer ese evento. Además es posible que no sea el único servicio que lea dicho mensaje por lo que es responsabilidad de cada consumidor el ser capaz de leer el mensaje.
La comunicación de los mensajes no se hace directamente sino que se hace a través de un intermediario, el cual es denominado message broker, y ya bien sea una cola o un stream de mensajes, su función es propagar la información, en este caso eventos, a sus consumidores, los cuales son servicios de nuestro sistema.
A esta acción se le llama patrón productor consumidor y es en el patrón en el que se basan las arquitecturas enfocadas a eventos.
Luego para implementar esa cola tienes muchas opciones, en el caso del canal hemos visto RabbitQM, pero yo he trabajado de forma profesional con kafka, kinesis streams, Azure service Bus, SQS, etc las opciones son prácticamente infinitas, pero la forma en la que trabajan es muy similar y todos tienen el mismo objetivo, mover el mensaje del punto A al punto B .. N.
2 - El impacto de una arquitectura basada en eventos
Cuando tenemos una única aplicación en un monolito, la tenemos corriendo en un servidor y ya está, tenemos un único punto de conexión a la base de datos. Al utilizar una arquitectura en eventos la cosa cambia, ya bien tengas una única base de datos o una base de datos por aplicación vas a tener múltiples puntos donde tu sistema necesita dicha configuración.
E igual que incluyo la base de datos, no olvidar el sistema de mensajería, del que depende todo el sistema, ya que si por lo que sea dicho sistema peta, no vamos a tener ni productores de mensajes ni consumidores de los mismos.
Por lo que nuestro sistema no va a funcionar como debería; al final tener una arquitectura basada en eventos te obliga a tener una mayor infraestructura y por supuesto un mayor control sobre dicha infraestructura.
Separar cada servicio te da un nivel de desacoplamiento y libertad para cada sistema que es muy bueno, pero en contra necesitas un sistema de monitoreo muy bien configurado ya que cuando hay un error, suele ser más difícil encontrar donde está el error, la automatización de procesos también es muy importante en este tipo de sistemas, porque no es lo mismo desplegar un monolito de forma manual una vez al mes, que desplegar 20 aplicaciones diarias.
Hacer cosas básicas dentro de un monolito como una transacción se convierten en sistemas y procesos bastante enrevesados con el patrón SAGA cuando utilizamos una arquitectura de eventos, el cual es muy costoso en términos no solo de infraestructura pero de material humano para desarrollarlo.
A su vez, da libertad a cada sistema/servicio/equipo para utilizar la mejor tecnología para solucionar el problema que necesita solucionar.
Por ejemplo, si necesitas usar caché en cierta aplicación lo incluyes en dicha aplicación, no necesitas que todo el sistema tenga acceso a dicha caché.
Y técnicamente da igual si un proceso tarda 500 ms o 10 segundos pues los eventos suceden de manera asíncrona, por lo que no hay un usuario u otro sistema que esté esperando por la respuesta inmediata.
2.1 - El escalado en la arquitectura basada en eventos
Muchos te van a decir que “Los monolitos no escalan”; esto es completamente erróneo, la frase correcta sería “Los monolitos no escalan de una forma económica”; porque amigos, con dinero infinito, todo escala.
Una de las características principales de los entornos de microservicios (y por supuestos de las arquitecturas basadas en eventos) es que puedes escalar aplicaciones de forma individual, en un monolito tendrías que escalar el monolito entero, que obviamente es peor ya que lo normal es querer escalar parte de él, pero por poder, se puede.
Aunque, obviamente, es mucho mejor en una arquitectura basada en eventos porque al tener aplicaciones mas pequeñas podemos escalar únicamente dichas aplicaciones.
Te pongo dos casos donde se entiende, Amazon, la tienda hace la gran mayoría de sus ventas por la tarde, mientras que por la mañana la gente está observando la tienda, para ver qué comprar.
Durante la mañana necesitan tener múltiples instancias del servicio de productos, ya que al estar todo el mundo buscando, tienen mucho más trabajo.
Al llegar la tarde, la búsqueda es mucho menor, la gente va a su carrito y ya sabe que es lo que quiere, por lo tanto podemos quitar un par de instancias de productos, dejando lo mínimo y necesario y ampliamos las de pedidos para que todos esos pedidos se procesen sin ningún problema.
Lo mismo sucede si trabajamos en una empresa de camiones o de alquiler de vehículos, nuestros vehículos llevan un dispositivo el cual envía notificaciones de donde está, velocidad, etc cada 30 segundos, pero si el coche está apagado, con enviar cada 10 minutos es suficiente.
Esto quiere decir que por la noche, o fuera del horario laboral vamos a tener una carga muchísimo menor que durante el día.
Por lo tanto escalaremos para que durante las horas laborales, tengamos un número superior de instancias de nuestra aplicación consumidora que durante la noche.
Lo mismo podemos observar a la hora de comer, donde el número de instancias que necesitamos baja ya que los vehículos están parados.
Por supuesto todas estas subidas y bajadas se hacen (o deberían) de forma automática.
2.2 - Necesito un sistema basado en eventos?
Si te estás haciendo esta pregunta, lo más probable es que no.
Administrar un sistema distribuido o basado en eventos no es fácil, de hecho es muy difícil así que si estas empezando a desarrollar tu aplicación te recomendaría que empezaras con un único monolito ya que luego ya tendrás tiempo de migrar, o si no quieres migrar de hacer las nuevas partes separadas en distintos servicios, pero de primeras, empieza con un monolito, no cometas el error de tener sistemas distribuidos cuando tienes cinco clientes y diez llamadas por minuto.
Los sistemas distribuidos son un campo muy extenso, yo tengo un curso completamente gratuito que puedes ver aquí.
