Arquitectura dirigida por eventos: producir, publicar, consumir
La arquitectura dirigida por eventos en un lienzo interactivo: productores, bus de eventos, suscriptores y almacén de eventos, y cómo el desacoplamiento deja entrar a nuevos consumidores sin tocar a los productores.
La arquitectura dirigida por eventos desacopla los sistemas haciendo que se comuniquen mediante eventos: los productores publican lo que ha pasado, el bus lo enruta a los suscriptores y un almacén de eventos guarda el historial.
Arquitectura dirigida por eventos: producir, publicar, consumir
El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este diagrama
- Lee de izquierda a derecha: emitir, publicar, consumir y retener.
- La fila de productores nunca apunta a un consumidor: cada flecha cruza el bus, y eso es el desacoplamiento hecho visible.
- La rama de abajo es el almacén de eventos: los mismos eventos que se consumen en tiempo real se conservan también para reproducirlos y auditarlos.
Producir y publicar
«Los servicios producen eventos de dominio» es toda la responsabilidad del productor: dejar constancia de que algo ha pasado. «Los eventos se publican en el bus» y «El bus enruta los eventos a los suscriptores» son el paso de publicación: el bus acepta los eventos y los entrega a quien se haya suscrito. El comentario de la caja de emisión hace explícita la regla: los productores no saben quién está escuchando, y eso es lo que hace extensible el sistema.
Consumir en tiempo real
«Los consumidores procesan los eventos de forma asíncrona» es el camino de la derecha: los suscriptores actúan sobre cada evento —actualizar un modelo de lectura, enviar un correo, disparar un flujo de trabajo— a su propio ritmo. El procesamiento asíncrono es la razón de que un consumidor lento no frene a un productor, y de que el diagrama mantenga a los dos en bandas separadas.
Conservar el historial
«El almacén de eventos conserva el historial completo» guarda cada evento en orden, y «Los eventos se pueden reproducir para auditoría o recuperación» es para lo que sirve esa constancia: reconstruir un estado, responder a una pregunta de auditoría o alimentar a un consumidor nuevo desde el pasado. «Los nuevos consumidores se incorporan sin tocar a los productores» es la prueba de la arquitectura: como el historial existe y el bus enruta por suscripción, añadir un servicio no cambia nada aguas arriba.
Relaciones clave y conclusiones
- Un evento registra lo que ha pasado; no es una orden para nadie en concreto.
- El bus desacopla a los productores de los consumidores: ninguno conoce la identidad ni el ritmo del otro.
- El almacén de eventos convierte el historial en un sistema de registro autorizado que se puede reproducir.
- Los consumidores son asíncronos: un consumidor lento nunca bloquea a un productor.
- Los nuevos consumidores se incorporan suscribiéndose, y toda la flexibilidad que reclama la arquitectura descansa en eso.
Cuándo usar este diagrama
- Enseñar la división productor-bus-consumidor a un equipo que pasa de petición/respuesta a eventos.
- Diseñar una integración nueva: el almacén de eventos responde a si hay que conservar el historial o basta con consumirlo y olvidarlo.
- Auditar un sistema dirigido por eventos ya existente en busca del fallo clásico: un consumidor que en realidad es una dependencia síncrona.
Cómo funciona
Renombra a las partes con las de tu sistema
Sustituye los productores, los consumidores y los nombres de eventos por tus servicios reales y los eventos que publican, y añade los que el diagrama genérico no cubre.
Nombra los topics y sus consumidores
Anota cada evento del bus con el nombre del topic y con quién se suscribe, para que el desacoplamiento sea un mapa documentado y no una afirmación.
Añade las ramas de fallo
Inserta qué pasa cuando el bus está caído, cuando un consumidor muere a mitad de un evento o cuando un evento llega dos veces, cada caso con el mecanismo de idempotencia o de reintento que lo resuelve.
Amplía el almacén de eventos
Añade las reglas de retención y de reproducción que usa de verdad tu sistema —cuánto tiempo se guarda el historial y qué estados se reconstruyen a partir de él— para que la banda del almacén refleje tu política.
Preguntas frecuentes
¿Qué es la arquitectura dirigida por eventos?
Es un estilo arquitectónico en el que los componentes se comunican publicando eventos y suscribiéndose a ellos en lugar de llamarse entre sí directamente. Un servicio que crea o cambia algo publica un evento que describe lo que ha pasado; el bus lo enruta a cada suscriptor al que le interesa; y un almacén de eventos guarda el historial. Como los productores nunca nombran a sus consumidores, el sistema puede crecer sin tocar lo que ya existe.
¿Cuál es la diferencia entre un comando y un evento?
Un comando es una instrucción dirigida a un destinatario concreto —«procesa este pedido»— y espera un resultado. Un evento es la constancia de que algo ya ha pasado —«pedido creado»— y no nombra a ningún destinatario. La distinción importa porque los comandos acoplan al emisor con el receptor, mientras que los eventos dejan libre al receptor para cambiar. Los productores del diagrama solo emiten eventos, y eso es lo que mantiene suelto el bus.
¿Para qué sirve el almacén de eventos?
El almacén de eventos es el historial conservado del sistema: cada evento, en orden, de forma permanente. Sirve para tres cosas: auditoría (qué pasó y cuándo), recuperación (reconstruir el estado de un servicio reproduciendo sus eventos) y extensibilidad (un consumidor nuevo puede ponerse al día leyendo el pasado). El diagrama lo dibuja como la rama de abajo porque es un uso distinto de los mismos eventos que los consumidores procesan en tiempo real.
¿Cuáles son los modos de fallo de la arquitectura dirigida por eventos?
Los clásicos son: eventos entregados más de una vez (así que los consumidores tienen que ser idempotentes), eventos procesados fuera de orden (así que los consumidores tienen que gestionar el orden) y la cola de mensajes fallidos (dead letter queue), donde acaban los eventos que fallan una y otra vez. El procesamiento asíncrono del diagrama es lo que hace manejables estos casos —un consumidor puede reintentar sin bloquear al productor—, y por eso las ramas de fallo de los pasos son la mitad práctica del diseño.
Edita este diagrama en QueryChart (FlowJam)
Abre ese mismo lienzo dirigido por eventos como tu propio diagrama, renombra los productores y los consumidores con tus servicios y traza tus eventos.