Arquitectura Orientada a Eventos

Resumen

En una arquitectura orientada a eventos, los componentes del sistema no se llaman directamente entre sí. En su lugar, emiten eventos cuando algo relevante ocurre —«se creó una orden», «el pago fue aprobado», «el inventario bajó del umbral»— y otros componentes reaccionan a esos eventos de forma asíncrona. El productor no sabe quién consume el evento ni cuántos consumidores hay.

Importa porque desacopla servicios en el tiempo y en el espacio. El servicio de órdenes no necesita saber que existe un servicio de notificaciones, uno de facturación y uno de analítica. Simplemente emite OrderCreated y cada uno hace lo suyo. Eso permite agregar, quitar o modificar consumidores sin tocar al productor —cumpliendo OCP a nivel de arquitectura—.

Los eventos se transportan mediante un broker de mensajería —Kafka, RabbitMQ, SQS/SNS— o un event stream. La diferencia principal es que un broker tradicional entrega el mensaje y lo descarta, mientras que un stream —Kafka— lo retiene, permitiendo que nuevos consumidores lean eventos históricos.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

El sistema de notificaciones de un edificio. Cuando alguien toca el timbre de un departamento, no va puerta por puerta preguntando «¿vos pediste comida?». Toca el timbre del departamento correcto y solo ese residente reacciona. En EDA, cada evento tiene un destinatario lógico —el topic o routing key— y cada servicio se suscribe a los eventos que le importan.

Uso práctico

• ✅ Desacoplamiento: el productor no conoce a los consumidores.
• ✅ Escalabilidad independiente: los consumidores escalan según su propia carga.
• ✅ Resiliencia: si un consumidor falla, los eventos se acumulan en el broker y se procesan cuando se recupera.
• ✅ Auditabilidad: el log de eventos es un historial completo de lo que pasó en el sistema.
• ❌ Debugging más complejo: seguir la trazabilidad de un request a través de eventos asíncronos requiere correlacionar IDs.
• ❌ Consistencia eventual: los consumidores se actualizan después del productor, no atómicamente.

La EDA es el fundamento de patrones más específicos como CQRS, Event Sourcing y Saga.

Ejemplo trabajado: flujo de orden con EDA

Un ecommerce implementa el flujo de compra con eventos. order-service emite OrderPlaced. inventory-service lo consume y reserva stock —si falla, emite InventoryReservationFailed—. payment-service consume OrderPlaced y cobra. notification-service consume ambos y envía emails de confirmación o de error. Si el equipo de marketing quiere agregar un descuento por primera compra, agregan un nuevo consumidor de OrderPlaced sin tocar ningún servicio existente.

Evidencia

• Wikipedia, Event-driven architecture define el patrón, los componentes (event producers, consumers, channels) y las topologías broker y mediator.