Cómo funcionan los eventos en sistemas distribuidos

Las arquitecturas orientadas a eventos son una de las formas más potentes de modelar sistemas complejos en software moderno. Aprenderás cómo funcionan los productores, consumidores y buses de eventos, por qué importan en sistemas distribuidos y para qué tipo de problemas son la mejor herramienta si trabajas como arquitecto o desarrollador.

¿Qué es una arquitectura orientada a eventos?

Una arquitectura orientada a eventos se basa en transmitir mensajes que representan cosas que ya sucedieron en el sistema. No son órdenes ni peticiones: son hechos consumados. Y aquí viene lo interesante: ese cambio de mentalidad lo cambia todo.

En este modelo conviven dos roles clave. Los productores ejecutan comandos o acciones que modifican el estado general del sistema. Los consumidores son componentes que necesitan enterarse de lo que ya ocurrió para reaccionar.

¿Qué es un evento en software? Es la representación de algo que ya sucedió en el sistema, como una factura emitida o una venta cerrada. Lleva solo la carga necesaria para que otros componentes reaccionen, no toda la información del proceso original.

¿Cómo se conectan productores y consumidores?

La conexión rara vez es directa. Lo recomendable es una capa intermedia conocida como bus de eventos o buffer, que guarda los eventos emitidos y los notifica a uno o varios consumidores. Esta capa también mantiene los mensajes cuando no hay clientes activos escuchando, lo que aporta resiliencia.

Imagina un sistema que debe notificar cada vez que se emite una factura. El evento factura emitida no necesita cargar con todos los anexos ni con el peso completo del sistema de facturación. Basta con saber que la factura X fue emitida correctamente en el momento T1. A partir de ahí, cada consumidor decide qué hacer.

¿Por qué usar diseño basado en dominios en eventos?

El diseño basado en dominios, conocido como Domain Driven Design o DDD, es una técnica establecida desde principios del siglo XXI. Su valor está en construir un lenguaje ubicuo que permita comunicación fluida entre el equipo técnico y el negocio.

Con DDD puedes identificar con claridad qué dominio emite eventos, qué dominio debe escucharlos y cómo se relacionan en una línea de tiempo. Sin esa claridad, una arquitectura de eventos se convierte rápido en un caos de mensajes sin contexto.

¿Cómo manejas conceptos compartidos entre contextos?

Los problemas complejos suelen dividirse en varios contextos, y ahí aparecen las colisiones. Un mismo concepto puede vivir en más de un contexto con significados distintos.

Piensa en un sistema con dos contextos:

• Ventas: el cliente y el producto se relacionan con el cierre de una venta.
• Soporte: el cliente y el producto se relacionan con la apertura de un ticket.
• Eventos diferentes: cada contexto emite y consume notificaciones distintas aunque comparta nombres.

Por eso necesitas un lenguaje ubicuo y comunicación abierta con todo el equipo. Solo así diferencias cuándo el concepto cliente significa una cosa y cuándo significa otra.

¿Qué retos tiene una arquitectura de eventos?

Este estilo arquitectónico soluciona problemas complicados, pero también añade complejidad. Los retos más comunes giran alrededor del tiempo, el orden y la consistencia.

Vuelve al ejemplo de la factura. Uno de los consumidores puede ser una entidad pública que recibe millones de notificaciones de muchos sistemas a la vez. Otro consumidor puede ser un sistema de notificación por correo electrónico. La entidad pública puede ver caer su nivel de servicio por la carga, mientras que el correo se envía casi al instante. Resultado: el cliente recibe el email antes de que la entidad estatal procese el evento.

¿Qué son las colisiones en arquitecturas de eventos? Son situaciones donde varios consumidores procesan el mismo evento en líneas de tiempo distintas, generando inconsistencias en el orden de las reacciones del sistema.

¿Cómo diseñas líneas de tiempo consistentes?

Como arquitecto debes definir líneas de tiempo coherentes con el contexto del problema y con el nivel de servicio de cada componente. No todos los consumidores procesan al mismo ritmo, y eso debe estar previsto desde el diseño.

Esto también te obliga a pensar en transacciones. La transaccionalidad garantiza operaciones atómicas, pero en eventos llegas a manejar transacciones distribuidas, donde varios componentes que no son el mismo sistema participan en una sola operación lógica.

¿Cuándo conviene usar arquitectura orientada a eventos?

Este enfoque resuelve problemas complicados y complejos, sobre todo cuando hay múltiples sistemas que deben reaccionar de forma desacoplada a lo que ocurre. Suele apoyarse en microservicios como sus componentes naturales, aunque puedes tener microservicios sin eventos perfectamente.

Algunas señales de que tu problema encaja:

• Tienes múltiples consumidores que reaccionan al mismo hecho.
• Necesitas desacoplar productores de consumidores.
• Los componentes tienen niveles de servicio muy distintos entre sí.

¿Has trabajado ya con buses de eventos o estás evaluando moverte hacia este modelo? Cuéntame en los comentarios qué retos has encontrado en tus propios sistemas.