Entender la diferencia entre mensajes y eventos es clave para diseñar arquitecturas orientadas a servicios que escalen sin romperse. Aunque a primera vista parezcan lo mismo, su impacto en las transacciones de negocio, los contratos entre servicios y el manejo de excepciones es muy distinto. Si diseñas microservicios, esta distinción define si tu sistema responde con coherencia o termina en un caos distribuido.
Muchos ingenieros con experiencia tropiezan aquí porque mezclan ambos conceptos en sus diagramas y, cuando algo falla en producción, no saben si deben cancelar la transacción global o compensar un hecho que ya ocurrió. Vamos a desarmar la idea.
¿Qué es un mensaje en una arquitectura de microservicios?
Un mensaje es una pieza de comunicación que forma parte de una transacción de negocio que aún no ha terminado. Es decir, cuando un servicio envía un mensaje, el caso de uso global sigue abierto y puede retrasarse o cancelarse si algo falla más adelante.
Piensa en un usuario que crea una orden a través de un servicio de gestión de órdenes [00:53]. Ese servicio envía un mensaje a una cola, que es consumida por otro servicio encargado, por ejemplo, del pago. Aunque los tiempos de ejecución entre ambos servicios sean distintos, la transacción de negocio sigue siendo una sola: si el pago no se efectúa, la orden puede cancelarse por completo.
¿Qué caracteriza a un mensaje en microservicios? Es punto a punto, tiene un origen y un destino específicos, y pertenece a una transacción global que aún puede revertirse.
Por eso, en los diseños donde uses mensajes, debes señalar con claridad quién envía y quién recibe. No es una notificación abierta al mundo, es una conversación dirigida.
¿Qué es un evento y en qué se diferencia de un mensaje?
Un evento también puede iniciarse a partir de un comando del usuario, pero la diferencia está en el momento en que se publica: el evento se lanza cuando la microtransacción ya se completó [01:43]. Es un hecho pasado, sin marcha atrás.
Cuando publicas contenido, por ejemplo, ese contenido ya fue publicado. El evento notifica a quien quiera escuchar que algo ocurrió. En los canales de eventos puedes tener varios servicios suscritos, todos reaccionando al mismo hecho consumado.
¿Qué es un evento en arquitectura distribuida? Es la notificación de una microtransacción que ya terminó. Otros servicios pueden escucharla y reaccionar, pero el hecho original no se deshace.
Aquí es donde aparece el patrón saga: como no puedes revertir un evento pasado, lanzas eventos compensatorios que componen nuevas acciones sobre lo ya ocurrido. Si publicaste contenido y luego necesitas retirarlo, no deshaces la publicación, emites un nuevo evento que retira ese contenido.
¿Cuándo conviene usar mensajes y cuándo eventos?
La decisión depende del tamaño y la naturaleza de la transacción que estás modelando. Si la operación es grande, atraviesa varios servicios y necesita poder cancelarse de forma global, los mensajes son tu herramienta. Si la operación es pequeña, atómica y solo necesitas notificar que terminó, usa eventos.
Algunas pautas prácticas para decidir:
- Usa mensajes cuando la transacción de negocio está abierta y puede revertirse.
- Usa eventos cuando la microtransacción ya cerró y otros servicios solo deben reaccionar.
- Combina ambos cuando tu flujo tenga partes grandes coordinadas y partes pequeñas notificables.
- Documenta los contratos y el manejo de excepciones en cada caso para que el equipo de desarrollo no improvise.
¿Cómo se manejan las transacciones distribuidas en cada caso?
Con mensajes, una transacción distribuida puede simplemente cancelar la operación global si algo falla en alguno de los pasos. Es una lógica de todo o nada coordinada entre servicios.
Con eventos, en cambio, no cancelas: compensas. Aplicas patrones como saga para emitir nuevos eventos que sobrealimenten o ajusten lo que ya pasó. Por eso los eventos exigen pensar en la consistencia eventual, no en la atomicidad clásica.
¿Qué es el patrón saga? Es una forma de manejar transacciones distribuidas con eventos, donde cada paso completado se compensa con nuevos eventos en lugar de revertirse [02:22].
¿Por qué tu diseño debe dejar esto explícito?
Porque el equipo de desarrollo necesita saber qué contrato cumple cada servicio y cómo manejar las excepciones. Un diagrama ambiguo entre mensajes y eventos termina en bugs difíciles de rastrear, transacciones huérfanas o datos inconsistentes.
Cuando diseñes, marca con claridad:
- Si la comunicación es punto a punto (mensaje) o publicación abierta (evento).
- Si la transacción puede cancelarse o solo compensarse.
- Qué servicios escuchan cada canal y cómo reaccionan ante fallos.
Estos dos conceptos son la base de los patrones de integración que vienen después, empezando por productores y consumidores. ¿Tú cómo los estás separando hoy en tus diseños? Cuéntame en los comentarios.
