Arquitectura orientada a eventos: qué es y cuándo conviene

Un evento es un registro de que algo ocurrió: un pedido fue creado, un pago fue aprobado o un archivo quedó disponible. En una arquitectura orientada a eventos, un productor publica ese hecho y uno o varios consumidores deciden qué hacer con él, en lugar de encadenar todas las acciones en una llamada directa.

También puede servirte: Qué es un rate limit en una API y cómo aplicarlo

El evento describe un hecho pasado y no debería depender de que el consumidor responda en el mismo instante. Esa separación permite que un componente publique una vez y que varias funciones reaccionen con sus propios ritmos. También obliga a definir cómo se conserva, entrega y vuelve a procesar el mensaje.

Event-driven no significa que toda la aplicación deba ser asíncrona. Un sistema puede combinar solicitudes síncronas para una respuesta inmediata con eventos para notificaciones, índices, auditoría o tareas que no necesitan bloquear la operación principal. La decisión depende del flujo y de sus garantías.

El productor emite el evento cuando confirma que el hecho ocurrió. Un broker o servicio de mensajería recibe, almacena y entrega los mensajes según su modelo. Los consumidores leen esos eventos y ejecutan una reacción, como actualizar una vista, enviar un aviso o iniciar un proceso.

El broker puede entregar un mensaje a un consumidor o a varios grupos, según la configuración. Hay sistemas que conservan eventos para permitir una lectura posterior y otros que priorizan una cola de trabajo. La retención, el orden y el reconocimiento deben definirse antes de elegir una tecnología.

La conexión indirecta reduce dependencias entre equipos, pero agrega operaciones que hay que observar. Un consumidor puede estar caído, recibir un evento dos veces o procesarlo fuera de orden. El diseño necesita identificadores, reintentos, una política para mensajes imposibles y una forma de consultar el estado del flujo.

Los eventos sirven para desacoplar reacciones que no tienen que ocurrir dentro de la misma respuesta. También permiten incorporar un nuevo consumidor sin modificar el productor, si el contrato del evento conserva los datos necesarios. Esa flexibilidad puede ser útil cuando varias áreas procesan el mismo hecho.

La contracara es que el sistema deja de tener una única transacción visible. Un pago confirmado puede tardar en aparecer en una vista, y una falla posterior puede requerir compensar una acción. El equipo debe explicar qué significa que un proceso esté completo y qué estado ve la persona usuaria mientras espera.

La consistencia eventual no es una excusa para perder datos. Hay que elegir qué ocurre si el broker no está disponible, si un consumidor falla después de guardar un resultado o si llega una versión nueva del evento. Las decisiones se prueban con fallos controlados y registros que permitan reconstruir la secuencia.

En una coreografía, cada consumidor reacciona a eventos y publica otros sin un coordinador central. El flujo puede ser simple al principio, pero con muchos pasos se vuelve difícil ver quién inicia una reacción y qué ocurre cuando falta un evento. Los contratos y la trazabilidad son esenciales para conservar el mapa.

En una orquestación, un componente coordina los pasos y decide qué comando o evento sigue. Esa centralización hace visible el proceso y facilita algunas compensaciones, aunque el orquestador se convierte en una dependencia que debe escalar y mantenerse disponible.

No hay una opción universal. La coreografía puede encajar en reacciones independientes; la orquestación suele ser más clara cuando hay una secuencia de estados, permisos y compensaciones. Antes de elegir, escribí el flujo de éxito y los caminos de error con nombres que el equipo pueda revisar.

Definí qué hechos deben quedar registrados, quién los publica y qué consumidores necesitan cada campo. Versioná el esquema, asigná un identificador único y decidí si el orden importa. También hay que documentar retención, reintentos, duplicados, mensajes inválidos y la ventana de consistencia que acepta el producto.

Instrumentá productor, broker y consumidores con métricas de demora, errores y mensajes pendientes. Relacioná logs y trazas con el identificador del evento y protegé los datos personales. Una cola sin visibilidad puede ocultar una demora que la persona usuaria interpreta como un fallo.

Por último, probá la caída del consumidor, la entrega duplicada, un cambio de esquema y la recuperación del broker. Si el equipo no puede explicar cómo reanudar el flujo sin duplicar efectos, todavía no hay una arquitectura operable. Los eventos desacoplan componentes; las garantías siguen siendo responsabilidad del diseño.