¿Qué es la arquitectura orientada a eventos (EDA)?

Arquitectura orientada a eventos es un estilo de diseño donde los servicios anuncian hechos inmutables como eventos y los consumidores reaccionan por su cuenta. La precisión que las páginas de proveedores se saltan vive en dos palabras: un evento es un hecho inmutable, en pasado — OrderPlaced, no PlaceOrder — y al productor no le consta ni le importa quién reacciona. Esa indiferencia es la arquitectura: los consumidores se agregan, se quitan y se rompen sin que el productor cambie una línea — desacoplamiento en su sentido más literal. Y la EDA es un espectro, no una religión — un solo webhook ya es orientado a eventos; una flota de streaming también; la mayoría de los sistemas sanos son híbridos.

Puntos clave

Un hecho, muchas reacciones

// JavaScript — Cloud Code (cloud/main.js)
// Everyday EDA: the write IS the event; consumers react independently
Parse.Cloud.afterSave('Order', async (req) => {
  const order = req.object;
  const becamePlaced = order.get('status') === 'placed' &&
    req.original?.get('status') !== 'placed';
  if (!becamePlaced) return;

  // Consumers of one fact — none knows about the others:
  await Parse.Cloud.httpRequest({          // fulfillment system (webhook)
    method: 'POST', url: process.env.FULFILL_WEBHOOK,
    body: { event: 'order.placed', id: order.id },
  });
  await enqueueConfirmationEmail(order);   // async job queue
  // Live Query pushes the change to every open dashboard automatically
});

// Flutter / Dart — Back4app Flutter SDK
// The client as event consumer: subscribe to facts, react on arrival
final orders = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'placed');
final sub = await LiveQuery().client.subscribe(orders);
sub.on(LiveQueryEvent.create, (order) => showNewOrder(order));
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

// iOS / Swift — Back4app Swift SDK
// The client as event consumer: subscribe to facts, react on arrival
let orders = Order.query("status" == "placed")
let sub = try await orders.subscribe()
sub.handleEvent { _, event in
    if case .created(let order) = event { showNewOrder(order) }
}
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

// Android / Kotlin — Back4app Android SDK
// The client as event consumer: subscribe to facts, react on arrival
val orders = ParseQuery.getQuery<ParseObject>("Order")
orders.whereEqualTo("status", "placed")
val sub = ParseLiveQueryClient.Factory.getClient().subscribe(orders)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, order ->
    showNewOrder(order)
}
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

Un hecho — un pedido quedó realizado — y cuatro consumidores, ninguno al tanto de los demás: un sistema de fulfillment notificado por webhook, un job de email encolado, el analytics contando, dashboards actualizándose por una suscripción en vivo. Agregar un quinto consumidor no cambia nada upstream. Ese es el argumento completo, en un solo save.

El vocabulario, desenredado

El caos terminológico de los buscadores, resuelto en una tabla — tres tipos de mensaje por intención, no por transporte:

La advertencia de Fowler merece la cita: cuidado con el comando pasivo-agresivo — un “evento” que el productor emite exigiendo en secreto que un consumidor específico actúe. Si el flujo se rompe cuando ese consumidor no responde, era un comando desde el principio, y llamarlo evento solo escondió el acoplamiento. (Las palabras de infraestructura — broker, router, bus, canal, topic — son casi sinónimos para la caja del medio; la entrada de pub/sub cubre esa maquinaria, de la cual la EDA es la arquitectura generalizadora.)

Orientado a eventos vs. request-response

La regla de una frase: si quien llama necesita el resultado para continuar, request-response; si el trabajo del productor está completo antes de que empiece cualquier reacción, eventos. Realizar el pedido necesita una respuesta síncrona (“¿funcionó?”); todo lo que viene después — email, fulfillment, analytics — son reacciones a un hecho, y por eso los sistemas reales son híbridos por diseño, no por concesión.

Los tres sabores de Fowler — y dónde encaja realmente el event sourcing

La desambiguación que ahorra reuniones: event sourcing es cómo un sistema almacena datos; EDA es cómo los sistemas conversan. Se componen entre sí, pero ninguno exige al otro. Una línea más que los proveedores difuminan: la entrega pub/sub olvida — los suscriptores tardíos pierden lo que se disparó antes de llegar — mientras que el streaming (el log ordenado al estilo Kafka) recuerda, dejando que los consumidores repitan desde cualquier punto; elige según la historia forme parte o no del producto.

Coreografía vs. orquestación

La regla espejo, compartida con la entrada de orquestación: orquesta cuando alguien debe ser dueño del resultado de un flujo; coreografía cuando a los productores genuinamente no les importa lo que viene después. Las transacciones de negocio largas entre servicios toman la forma de saga en ambos casos — transacciones locales encadenadas por eventos o por un orquestador, deshechas por compensaciones en vez de rollback.

EDA del día a día — sin broker

La sección que los centros de arquitectura nunca escriben: la mayoría de los desarrolladores de apps ya corre patrones orientados a eventos sin ningún broker de mensajes a la vista. Un trigger beforeSave/afterSave es un consumidor de eventos de cambio de datos. Un webhook es un evento cruzando fronteras entre empresas por HTTP puro. Una live query es pub/sub con clientes como suscriptores. Un job en segundo plano encolado por un trigger es un evento generando trabajo asíncrono. Las pestañas de código de arriba son exactamente esa pila — la escritura es el evento, el trigger es el router, y los consumidores son un webhook, una cola y una suscripción. Los brokers dedicados (Kafka, RabbitMQ, NATS — con CloudEvents como sobre estándar) justifican su peso operativo cuando el volumen de eventos, el replay y los contratos entre equipos lo exigen; la arquitectura empieza mucho antes, y “¿necesito un broker?” suele responderse solo: todavía no.

Casos de uso comunes

• Flujos de pedido y pago — un hecho, muchos departamentos: el pipeline canónico del e-commerce.
• Integración entre sistemas — servicios de equipos distintos reaccionando sin llamadas directas ni deploys compartidos.
• Funciones en tiempo real — dashboards, feeds y presencia como consumo de eventos de cara al cliente.
• Cargas con picos — colas amortiguando ráfagas para que los consumidores drenen a su propio ritmo.
• Auditoría y replay — logs de streaming donde “qué pasó, en orden” es el producto en sí.

¿Deberías adoptar la arquitectura orientada a eventos? Matriz de decisión

Limitaciones y trade-offs

• El debug pierde la call stack. Una solicitud que se abre en cinco saltos asíncronos solo es rastreable por IDs de correlación cargados desde el primer evento — el retrofit es doloroso; instálalos desde el primer día.
• La consistencia eventual llega a la UI. El usuario actualiza su perfil y la siguiente pantalla muestra el nombre viejo; diseña la UX para eso o mantén ese camino síncrono.
• Los duplicados son contractuales. La entrega at-least-once vuelve obligatorios los consumidores idempotentes — el mismo contrato que imponen las colas, porque es la misma maquinaria.
• Los esquemas evolucionan bajo los pies de los consumidores. Los eventos son contratos con suscriptores desconocidos: solo cambios aditivos, topics versionados para las rupturas y lectores tolerantes en todas partes.
• Los flujos emergentes se esconden. La coreografía pura significa que nadie puede señalar el proceso de negocio; cuando los auditores o la guardia lo necesiten, agrega el orquestador.

Patrones orientados a eventos en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La sección de EDA del día a día es su lista de funciones leída como arquitectura: cada save es un evento, los triggers afterSave son consumidores server-side con el ecosistema JavaScript completo, las Live Queries reparten los hechos a los clientes por WebSockets gestionados, los webhooks los llevan a sistemas externos y los jobs en segundo plano absorben las reacciones lentas — las pestañas de código muestran el ciclo completo a partir de un save de pedido. Las disciplinas que este artículo exige siguen siendo tuyas (after-hooks idempotentes, pensamiento en pasado, síncrono donde quien llama necesita respuesta), mientras que la infraestructura con forma de broker — fan-out, entrega, flotas de conexiones — llega como comportamiento de plataforma, y graduarse después a un broker de streaming dedicado es una adición a esta arquitectura, no una reescritura.