Arquitectura dirigida por eventos

¿Qué es la arquitectura dirigida por eventos?

La arquitectura dirigida por eventos es una forma de construir sistemas donde los componentes se comunican produciendo y reaccionando a eventos en vez de llamarse entre sí directamente. Un servicio hace algo, anuncia que ocurrió y sigue adelante. Otros servicios escuchan ese anuncio y actúan en consecuencia. El productor nunca sabe ni le importa quién está escuchando, lo que mantiene las partes débilmente acopladas.

Compáralo con el modelo petición-respuesta que usan la mayoría de las APIs, donde un servicio llama a otro y espera una respuesta. Funciona, pero ata los servicios con fuerza entre sí. Si el servicio llamado va lento o está caído, el que llama se queda atascado. En un montaje dirigido por eventos, un servicio de pedidos puede publicar un evento "pedido realizado", y los servicios de facturación, inventario y correo reaccionan cada uno a su ritmo. Cuando un cliente hace el checkout de una tienda online, ese único evento puede disparar un cargo de pago, una rebaja de stock y un email de confirmación sin que el flujo de checkout espere a ninguno de ellos.

El compromiso es la complejidad. Un flujo que era una línea recta se convierte en una red de reacciones, más difícil de rastrear y depurar. También tienes que pensar en el orden, en los eventos duplicados y en qué pasa cuando un consumidor falla. La recompensa son sistemas que escalan de forma independiente y absorben la carga, ya que los eventos pueden encolarse y procesarse cuando los consumidores están listos en vez de desbordar una cadena de llamadas síncrona.

Arquitectura dirigida por eventos en Dallonses

Usamos patrones dirigidos por eventos donde se ganan su sitio, normalmente cuando un sistema tiene varias tareas que pueden ocurrir de forma independiente tras un disparador. Un cliente de retail necesitaba que el checkout siguiera rápido mientras un montón creciente de trabajo posterior se le iba acumulando detrás: comprobaciones de fraude, fulfilment, puntos de fidelidad, analítica. Movimos ese trabajo detrás de eventos para que el camino de cara al cliente siguiera ágil y cada servicio posterior pudiera escalar y fallar por su cuenta sin arrastrar al resto.

No es la respuesta correcta para todo proyecto, y somos honestos con eso, porque el coste de depuración es real. Cuando sí encaja, nuestro trabajo de integración de API y de plataformas se apoya en ella para conectar sistemas que no deberían estar esperándose unos a otros. Diseñamos los eventos, los contratos y el manejo de fallos por adelantado, para que el acoplamiento débil siga siendo un activo en vez de convertirse en un sistema que nadie puede seguir.

¿Tienes sistemas que deberían reaccionar entre sí sin hacer cola? Diseñemos el flujo.

Hablemos de arquitectura