Cuando varias partes de un sistema necesitan reaccionar a lo que ocurre en otra, la llamada directa acumula acoplamiento. La arquitectura orientada a eventos propone lo contrario: quien produce un hecho no necesita saber quién lo consume. Ese simple cambio de enfoque desacopla el tiempo, el rendimiento y la evolución de cada parte.
Qué es un evento
Un evento representa algo que ya ocurrió: un pedido fue confirmado, un pago se aprobó, un usuario completó un registro. No es una orden (“haz esto”), sino un hecho registrado (“esto pasó”). Esa distinción es importante: el productor no da instrucciones, solo publica conocimiento.
Pub/sub y mensajería
El patrón base es el publica/suscribe: el productor envía el evento a un canal o bus, y cada consumidor se suscribe a los eventos que le interesan. Las ventajas son inmediatas:
- El productor no espera respuesta (no bloquea ni conoce al consumidor).
- Se pueden añadir consumidores nuevos sin tocar al productor.
- Cada parte escala de forma independiente.
El desacoplamiento en el tiempo es la ganancia principal: el consumidor puede estar caído o lento sin afectar al productor. El evento espera; nada se pierde.
Event sourcing: el evento como fuente de verdad
Un paso más allá, el event sourcing guarda la secuencia de eventos como registro histórico del sistema, en lugar de persistir solo el estado actual. Permite reconstruir el estado en cualquier punto del tiempo, auditar cambios y reaccionar a hechos pasados. Es potente, pero añade complejidad, así que conviene reservarlo para dominios donde el historial importa de verdad (finanzas, cumplimiento, trazabilidad).
Compensación en lugar de transacciones
En un sistema distribuido no existe la transacción tradicional entre servicios. Cuando un paso falla, el patrón habitual es la compensación: en vez de deshacer, se publica un evento que revierte o corrige el efecto anterior. Es la base de los patrones saga, donde cada flujo distribuido se orquesta mediante eventos.
Cuándo conviene desacoplar
- Cuando varias partes reaccionan al mismo hecho y no quieres mantener esa lista acoplada.
- Cuando el procesamiento puede ser asíncrono sin afectar la experiencia del usuario.
- Cuando necesitas trazabilidad y auditoría de los cambios.
Y cuándo no: cuando la respuesta debe ser inmediata y consistente, la llamada síncrona sigue siendo más simple y predecible.
Desacoplar no es gratuito, pero bien dosificado reduce el acoplamiento de forma notable y hace al sistema más evolutivo.
En mis proyectos uso eventos donde aportan valor real, no por defecto. La arquitectura orientada a eventos es una herramienta poderosa cuando se aplica con criterio: en los flujos donde el desacoplamiento evita fricción y deja que cada parte evolucione a su ritmo.