Inicio › Tecnología › Arquitectura Orientada a Eventos
La arquitectura orientada a eventos es un modelo de diseño en el qué los componentes de un sistema se comunican mediante la emisión y el consumo de eventos —notificaciones de qué algo ha ocurrido, como 'pedido creado' o 'pago confirmado'— en lugar de mediante llamadas directas entre servicios qué esperan una respuesta inmediata. Un componente productor publica el evento en un broker o bus de mensajes (como Apache Kafka o RabbitMQ) sin saber ni preocuparse de quién lo va a consumir, y cualquier número de componentes suscritos reaccionan de forma independiente y asíncrona. Este desacoplamiento facilita añadir nuevos consumidores sin modificar el sistema qué produce el evento original, y mejora la resiliencia porque un consumidor caído no bloquea al resto del sistema, aunque introduce complejidad para razonar sobre el orden y la consistencia eventual de los datos.
En vez de qué un sistema llame directamente a otro y espere su respuesta antes de seguir, cada sistema anuncia 'esto acaba de pasar' (un evento) y quien esté interesado se entera y reacciona por su cuenta, sin qué el qué anunció el evento tenga ni qué saber quién está escuchando. Es como una emisora de radio: emite la noticia y no le importa cuántos oyentes la reciben ni qué hacen con ella.
Cuando un cliente completa un pedido en tu tienda online, en vez de qué el servicio de pedidos llame directamente y en secuencia al servicio de email, al de facturación y al de inventario (acoplando los tres y haciendo qué un fallo en cualquiera bloquee la compra), publica un evento 'pedido-completado' en un bus de mensajes. Cada servicio interesado se suscribe y reacciona por su cuenta: el de email envía la confirmación, el de inventario descuenta stock, sin qué el servicio de pedidos necesite conocer su existencia ni esperar a qué terminen.
Una cola tradicional suele entregar cada mensaje a un único consumidor qué lo procesa y lo elimina; un bus de eventos como Kafka permite qué múltiples consumidores independientes lean el mismo evento, cada uno a su propio ritmo, conservando el histórico durante un periodo configurable.
Es la garantía de qué, aunque los distintos servicios no se actualicen todos en el mismo instante exacto, con el tiempo todos convergen al mismo estado consistente; aparece porque cada consumidor procesa el evento de forma asíncrona y a su propio ritmo.
Si un evento se pierde, se duplica o se procesa fuera de orden, el sistema puede quedar en un estado inconsistente; por eso los flujos críticos suelen exigir eventos idempotentes, mecanismos de reintento y auditoría, y en ocasiones un patrón de saga para coordinar transacciones distribuidas con compensación ante fallos.