Arquitectura dirigida por eventos: brokers, mediadores y flujos de eventos

Definición: reaccionar a lo que ocurre

En la arquitectura dirigida por eventos (EDA), los componentes se comunican produciendo eventos y reaccionando a ellos: registros de hechos que han ocurrido en el negocio, como se hizo un pedido o se asignó un repartidor. El componente que publica un evento no llama a los componentes que reaccionan a él y normalmente ni siquiera sabe que existen. Un intermediario de mensajes (message broker) lleva los eventos de los productores a los consumidores, los retiene mientras los consumidores están ocupados o caídos, y permite añadir consumidores nuevos sin cambiar el productor.

Los diseños dirigidos por eventos no son nuevos: las interfaces gráficas de usuario, los sistemas operativos y los sistemas de negociación bursátil llevan décadas funcionando así, y los productos de mensajería empresarial son anteriores a la web. Lo que cambió en la década de 2010 fue la escala y la durabilidad. Los brokers basados en logs, como Apache Kafka, creado en LinkedIn y publicado como código abierto en 2011, hicieron viable conservar cada evento de negocio durante días o años y volver a reproducirlos. La EDA puede ser el estilo principal de un sistema o, con más frecuencia, la forma en que se comunican entre sí los servicios de un sistema de microservicios o basado en servicios.

Eventos, comandos y mensajes

Hay tres palabras que a menudo se usan sin precisión, y la diferencia importa. Un mensaje es el sobre: cualquier dato enviado de un programa a otro a través de un canal. Lo que transporta el mensaje puede ser un evento (un hecho, nombrado en tiempo pasado), un comando (una solicitud dirigida a un único manejador, nombrada como una instrucción) o una consulta y su respuesta. Enterprise Integration Patterns (2003), de Gregor Hohpe y Bobby Woolf, catalogó estos tipos de mensaje y los canales que los transportan, y su vocabulario sigue siendo el estándar.

Los mensajes viajan por dos tipos de canal. Una cola entrega cada mensaje a uno de sus consumidores, lo que encaja con los comandos y el reparto de trabajo. Un topic entrega una copia de cada mensaje a cada suscriptor, lo que es publicación-suscripción (pub-sub) y encaja con los eventos. Un diseño que envía OrderPlaced a un topic permite que Pagos, Restaurante, Notificaciones y Analítica reaccionen, cada uno a su propio ritmo; añadir el año que viene un servicio de detección de fraude supone una suscripción nueva y ningún cambio en Pedidos.

Topología de broker y topología de mediador

Richards y Ford describen dos topologías para los sistemas dirigidos por eventos. En la topología de intermediario (broker) no hay un coordinador central. Se publica un evento inicial; cada procesador interesado reacciona y puede publicar más eventos, a los que otros reaccionan a su vez. El flujo de trabajo solo existe como la suma de esas reacciones. Esto es coreografía: como bailarines que conocen cada uno sus propios pasos, nadie dirige el conjunto.

En la topología de mediador, un mediador de eventos recibe el evento inicial y dirige el flujo de trabajo, enviando comandos a los procesadores en un orden definido y actuando según sus respuestas. Esto es orquestación: un director de orquesta conoce la partitura. Los mediadores van desde un servicio sencillo con una máquina de estados hasta un motor de flujos de trabajo como Temporal, AWS Step Functions o un motor BPMN.

La mayoría de los sistemas reales combinan ambas: coreografía entre contextos delimitados (Pedidos anuncia hechos y no le importa quién escucha) y orquestación dentro de un contexto cuando un proceso de varios pasos necesita un propietario claro.

Cuatro formas de usar los eventos

En un artículo de 2017, Martin Fowler señaló que 'dirigido por eventos' se usa para al menos cuatro patrones bastante diferentes, y que las conversaciones se tuercen cuando cada persona se refiere a uno distinto. Distinguirlos es uno de los hábitos más útiles que puede tener un arquitecto.

La notificación de eventos y la transferencia de estado transportada por eventos tratan de la comunicación entre servicios y pertenecen a este capítulo. El event sourcing y CQRS tratan de cómo almacena sus datos un servicio; a menudo se combinan con la EDA, pero son decisiones independientes, que se tratan en el Capítulo 7.

Flujos de eventos y logs: cómo funciona Kafka

Las colas de mensajes tradicionales eliminan un mensaje en cuanto un consumidor confirma su recepción. Un broker basado en logs, como Apache Kafka, en cambio, almacena los eventos en un log de solo anexado y los conserva durante un periodo de retención configurado (o para siempre), se hayan leído o no. De ese diseño se derivan varias cosas, que explican tanto los puntos fuertes de Kafka como sus trampas.

Un topic se divide en particiones, cada una de ellas un log ordenado que se almacena y se replica entre brokers. El productor elige la partición, normalmente aplicando un hash a la clave del evento, de modo que todos los eventos con la misma clave (por ejemplo, el mismo ID de pedido) van a la misma partición. Cada evento de una partición tiene una posición secuencial llamada su offset (desplazamiento). Los consumidores extraen los eventos y registran el offset al que han llegado; también pueden rebobinar y volver a reproducirlos.

Los consumidores se unen a un grupo de consumidores. Dentro de un grupo, cada partición la lee exactamente un consumidor a la vez, así que el grupo se reparte el trabajo; los distintos grupos leen de forma independiente, cada uno con sus propios offsets, y así se consigue el pub-sub. Por tanto, el número de particiones limita el paralelismo de un grupo: un topic con 12 particiones puede mantener ocupados como máximo a 12 consumidores de un grupo. (Kafka 4.2, lanzado en 2026, añadió los share groups como alternativa similar a una cola: varios consumidores pueden compartir una partición y confirmar los mensajes uno a uno, pero entonces no se conserva el orden dentro de la partición. Esta sección describe los grupos de consumidores clásicos).

Kafka garantiza el orden solo dentro de una partición. Los eventos de un pedido llegan en el orden en que se escribieron si comparten clave; los eventos de pedidos distintos, en particiones distintas, no tienen un orden definido entre sí. Los diseños que necesitan un orden global deben usar una sola partición (renunciando al paralelismo) o, mejor, rediseñarse para que solo importe el orden por entidad.

Garantías de entrega, y lo que significa realmente 'exactamente una vez'

Como las redes y los procesos fallan (Sección 6.1), un broker y sus clientes deben elegir qué ocurre cuando una caída o un timeout deja sin aclarar si un mensaje se procesó. Hay tres garantías posibles, y la elección depende de cuándo se registran las confirmaciones y los offsets.

'Exactamente una vez' necesita una definición cuidadosa. La entrega exactamente una vez a través de una red no fiable no es alcanzable en general: un emisor que no recibe confirmación no puede saber si debe reenviar. Lo que los sistemas pueden ofrecer es un efecto exactamente una vez dentro de un límite definido. Kafka, por ejemplo, ofrece un productor idempotente y transacciones desde la versión 0.11 (2017), de modo que un ciclo de lectura, procesamiento y escritura de topics de Kafka a topics de Kafka confirma su salida y los offsets de su consumidor de forma atómica. Esa garantía se detiene en el borde de Kafka. Si el consumidor cobra una tarjeta, envía un correo electrónico o escribe en otra base de datos, una caída entre esa acción y la confirmación del offset hará que la acción se repita, a menos que el propio consumidor sea idempotente o almacene sus offsets en la misma transacción que sus resultados.

Por eso, la regla práctica para los arquitectos es sencilla: da por hecho que la entrega es al menos una vez y haz que cada consumidor sea un consumidor idempotente. Da a cada evento un identificador único; en el consumidor, registra los identificadores procesados en la misma transacción local que el cambio de estado y omite cualquier evento ya registrado. Siempre que sea posible, haz también que la operación sea idempotente por naturaleza, por ejemplo 'poner el estado en PAID si está en AWAITING_PAYMENT' en lugar de 'añadir un pago'.

# Idempotent consumer: processing the same event twice has the effect of once
def handle_payment_authorised(event, db):
    with db.transaction():                       # one local ACID transaction
        inserted = db.execute(
            "INSERT INTO processed_events (event_id) VALUES (%s) "
            "ON CONFLICT (event_id) DO NOTHING",
            [event["event_id"]],
        ).rowcount
        if inserted == 0:
            return                               # seen before: do nothing
        db.execute(
            "UPDATE orders SET status = 'PAID' WHERE order_id = %s "
            "AND status = 'AWAITING_PAYMENT'",
            [event["order_id"]],
        )
    # commit the broker offset only after the transaction has committed

Esquemas y versionado de los eventos

Una vez que otros equipos consumen un evento, su estructura es un contrato publicado, igual que una API, y dura más: con un broker basado en logs, los consumidores pueden leer eventos escritos hace meses. Un buen evento tiene un identificador único, un tipo, una versión del esquema, el momento en que ocurrió, los identificadores de las entidades implicadas y los datos de negocio que necesitan los consumidores. El dinero se almacena en unidades menores con una divisa, nunca como un número de coma flotante (Capítulo 0).

{
  "event_id": "9f1c2e7a-4b0d-4e55-9a51-0c3d8f2b6a10",
  "type": "OrderPlaced",
  "schema_version": 2,
  "occurred_at": "2026-10-22T18:42:07Z",
  "order_id": "ord-4711",
  "customer_id": "cus-208",
  "restaurant_id": "res-31",
  "items": [{"dish_id": "d-5", "qty": 2, "price_minor": 1150}],
  "total_minor": 2450,
  "currency": "GBP"
}

Los esquemas deben evolucionar de forma compatible hacia atrás: añadir campos opcionales, nunca eliminar ni renombrar campos ni cambiar su significado sin una versión nueva, y nunca reutilizar el nombre de un campo para algo distinto. Muchos equipos lo imponen con un formato de esquema como Avro, Protocol Buffers o JSON Schema y un registro de esquemas que rechaza los cambios incompatibles en el momento de publicar. La especificación CloudEvents, un proyecto graduado de la Cloud Native Computing Foundation, estandariza los atributos comunes del sobre, como id, source, type y time. Los modos de compatibilidad y las técnicas de migración se tratan en evolución de esquemas.

Manejo de errores: reintentos, mensajes envenenados y colas de mensajes fallidos

Los consumidores fallan por dos motivos muy diferentes, y necesitan un tratamiento distinto. Los fallos transitorios, como una base de datos que no está disponible durante un momento o un timeout al llamar a otro servicio, suelen tener éxito al reintentar; reintenta unas pocas veces con backoff exponencial y jitter (esperas crecientes y aleatorias) para no saturar una dependencia que ya tiene problemas. Los fallos permanentes, como un evento mal formado o uno que infringe una regla de negocio, fallarán siempre. Un 'mensaje envenenado' (poison message) así no debe bloquear al consumidor para siempre, lo que en un log particionado detendría todos los eventos posteriores de esa partición.

La respuesta estándar es una cola de mensajes fallidos (dead-letter queue, DLQ): tras un número fijado de intentos, el mensaje se mueve a un canal aparte, con el error registrado, y el consumidor sigue adelante. Una DLQ solo es útil si alguien la vigila: genera alertas según su tamaño, asigna su propiedad a un equipo concreto, ofrece herramientas para inspeccionar, corregir y volver a reproducir los mensajes, y decide de antemano qué garantías de orden se pierden cuando un mensaje se reproduce tarde. Algunos equipos añaden uno o más topics de reintento intermedios con esperas más largas antes de la DLQ.

Cuándo usarla y errores habituales

La arquitectura dirigida por eventos encaja cuando muchas partes de un negocio deben reaccionar a los mismos hechos, cuando el trabajo puede hacerse después de que responda la solicitud del usuario, cuando la carga llega a ráfagas y hay que suavizarla, y cuando se esperan consumidores nuevos con el tiempo. Encaja peor cuando un usuario necesita una respuesta inmediata y definitiva que depende de varios servicios (aunque una llamada síncrona para la respuesta más eventos para el seguimiento es un híbrido habitual), o cuando se exige consistencia fuerte entre servicios.