Arquitectura dirigida por eventos · Mapas mentales
Arquitectura dirigida por eventos. Un mapa mental editable con ramas de colores, ideas secundarias y conexiones. Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
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 · Mapas mentales
El lienzo interactivo de MindMap 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 mapa mental
- Empieza por el tema central y sigue una rama de color para explorar sus ideas.
- Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
Producers
Esta rama reúne “An event records something that HAPPENED — “order placed”, “user updated” — not an instruction to anyone in particular. Producers don't know who is listening.”.
Event bus
Esta rama reúne “Events are published to the bus”, “The bus decouples producers from consumers: a producer keeps publishing whether or not any consumer is ready, and consumers subscribe to the events they care about.”.
Consumers
Esta rama reúne “Consumers process events asynchronously”, “The test of the architecture: add a service that reacts to existing events, and not one producer changes. This is the flexibility the pattern buys.”.
Event history
Esta rama reúne “The event log is the system of record: every state change, in order, forever. Current state is a projection that can be rebuilt from it.”, “Events can be replayed for audit or recovery”.
Conexiones entre ramas
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.
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
Adapta el tema central
Cambia el nombre del tema para adaptarlo a tu proyecto o clase.
Desarrolla las ramas
Edita las ideas y añade ejemplos o notas.
Conecta ideas relacionadas
Dibuja conexiones entre ramas; usa flechas cuando la dirección importe.
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.
Editar este mapa mental en QueryChart
Abre este mapa mental en un lienzo editable. Mueve ideas, añade ramas y dibuja conexiones.