Introducción: Reaccionar a eventos
Event-Driven Architecture organiza el sistema alrededor de eventos. Los productores publican, los consumidores reaccionan.
Esto desacopla componentes y permite escalado flexible.
El precio del desacoplamiento es la complejidad: orden de eventos, consistencia eventual y necesidad de idempotencia en los consumidores.
Cuando el volumen crece, necesitas monitoreo, trazas y contratos de eventos bien versionados para evitar rupturas.
Prompt: Event bus with multiple subscribers, clean minimal style.
1. Naturaleza: Señales en el ecosistema
Un sonido de alerta activa respuestas distintas en diferentes especies.
El evento se emite una vez, pero tiene múltiples reacciones.
Algunas especies reaccionan de inmediato y otras lo hacen con retraso. Esa diferencia se parece a los consumidores rápidos y lentos en una arquitectura basada en eventos.
Prompt: Wildlife reacting to a sound wave, soft natural illustration.
2. Mundo Real: Notificaciones en tiempo real
Un pago genera eventos que actualizan inventario, envíos y facturación.
Cada servicio responde según su necesidad sin acoplarse al resto.
Si un servicio falla, el evento puede reintentarse o procesarse más tarde sin bloquear a los demás. Esa resiliencia es una de las razones principales para usar este estilo.
Prompt: Notification flow diagram, clean flat style.
3. Implementación en C#: Código Paso a Paso
public class EventBus
{
public event Action Evento;
public void Publicar(string mensaje) => Evento?.Invoke(mensaje);
}
var bus = new EventBus();
bus.Evento += msg => Console.WriteLine($"Recibido: {msg}");
bus.Publicar("Pago confirmado"); En producción, un bus en memoria no es suficiente. Necesitas un broker confiable, manejo de reintentos y consumidores idempotentes para evitar duplicados.
También conviene definir contratos explícitos para cada evento y versionarlos para permitir evolución sin romper a los consumidores.
4. Event-Driven vs Request-Reply
Event-Driven es asíncrono y desacoplado; Request-Reply es directo y síncrono.
Usa eventos cuando quieras difusión y escalabilidad; usa request-reply para operaciones críticas.
Muchos sistemas combinan ambos: eventos para integración y APIs sincrónicas para lecturas o confirmaciones inmediatas.
5. Diagrama UML
Prompt: UML diagram of event-driven architecture, clean vector layout.
Prompt: Event flow diagram with publishers and subscribers, minimal infographic style.
⚠️ Cuándo NO Usar Event-Driven
- Si necesitas consistencia inmediata y transacciones fuertes.
- Si el sistema es muy simple y no requiere desacoplamiento.
- Si el equipo no cuenta con tooling de observabilidad o monitoreo.
💪 Ejercicio
Diseña un flujo de eventos para un sistema de pedidos con envío y notificaciones.
Conclusión
Event-Driven Architecture es clave para sistemas desacoplados y reactivos, pero requiere buena observabilidad.
Cuando defines eventos claros y consumidores idempotentes, obtienes un sistema flexible y resistente a cambios.