Una arquitectura basada en eventos (Event-Driven Architecture o EDA) es un modelo de arquitectura de software en el que aplicaciones y servicios se comunican mediante eventos, es decir, cambios de estado o hechos relevantes que otros componentes pueden detectar y procesar.
Este enfoque permite desacoplar productores y consumidores, ejecutar procesos de forma asíncrona y reaccionar ante lo que sucede en los sistemas en tiempo real o casi real.
En una arquitectura Event-Driven intervienen:
- productores de eventos,
- consumidores y,
- canales o brokers de eventos
Todos ellos se encargan de distribuir la información. Tecnologías como Apache Kafka, Confluent, RabbitMQ, AWS EventBridge, Google Cloud Pub/Sub o Azure Event Grid permiten implementar diferentes modelos de mensajería y event streaming en arquitecturas distribuidas, microservicios, sistemas cloud o entornos híbridos.
En esta guía veremos:
- cómo funciona una arquitectura basada en eventos (EDA),
- cuáles son sus componentes,
- qué diferencias existen entre Pub/Sub y Event Streaming,
- qué ventajas ofrece y,
- en qué casos tiene sentido utilizarla.
También abordaremos la parte que suele recibir menos atención:
- sus riesgos,
- cuándo puede añadir complejidad innecesaria y,
- cómo implantar una arquitectura basada en eventos (EDA) de forma gradual en una arquitectura existente.
¿Qué es una arquitectura basada en eventos (EDA) y cómo funciona?
Una arquitectura basada en eventos (EDA) es un modelo en el que los distintos componentes de un sistema reaccionan ante hechos que ya han ocurrido en lugar de depender únicamente de peticiones directas entre servicios.
Un evento representa un cambio de estado o un hecho relevante dentro de un proceso. Por ejemplo:
- Pedido #1234 completado
- Pago confirmado
- Stock por debajo del umbral
- Usuario registrado
- Temperatura de máquina fuera de rango
Una vez publicado, un evento representa un hecho que ha ocurrido y no debería modificarse. Otros sistemas pueden recibirlo y decidir qué acción ejecutar en respuesta.
El funcionamiento básico puede resumirse así:
- Ocurre un hecho. Un sistema detecta un cambio relevante.
- Un productor genera el evento. El servicio crea una representación del hecho.
- El evento se publica en un canal o broker.
- Uno o varios consumidores reciben o leen el evento.
- Cada consumidor ejecuta su propia lógica de manera independiente.
Imagina que un cliente completa una compra. El servicio de pedidos publica que el pedido está completado.
A partir de ese único evento:
- inventario puede actualizar el stock,
- logística puede preparar el envío,
- marketing puede actualizar el perfil del cliente;
- facturación puede generar la factura;
- analítica puede registrar la conversión.
El servicio que genera el evento no necesita llamar individualmente a todos esos sistemas ni conocer qué harán después.
Esa es una de las principales diferencias respecto a un modelo síncrono tradicional de petición-respuesta.
Sigue aprendiendo: EDA & API management: La fusión clave para APIs asíncronas gobernadas y escalables
Arquitectura síncrona vs. arquitectura basada en eventos (EDA)
En una arquitectura síncrona, un servicio solicita una acción a otro y normalmente espera su respuesta para poder continuar.
En una arquitectura basada en eventos (EDA), el productor comunica que algo ha sucedido, y los consumidores reaccionan de forma independiente.
| Arquitectura síncrona | Arquitectura Event-Driven |
| Comunicación directa entre servicios | Comunicación mediante eventos |
| El solicitante conoce al receptor | El productor no necesita conocer a los consumidores |
| Normalmente espera respuesta | Procesamiento habitualmente asíncrono |
| Mayor dependencia temporal | Mayor desacoplamiento temporal |
| Adecuada para operaciones que necesitan respuesta inmediata |
Adecuada para reacciones, propagación de cambios y procesamiento distribuido |
Esto no significa que una arquitectura deba ser completamente síncrona o completamente basada en eventos.
En entornos empresariales es habitual que ambos modelos convivan, las APIs síncronas resuelven unas necesidades y los eventos asíncronos otras.
¿Cuáles son los componentes esenciales de una arquitectura Event-Driven?
Una arquitectura basada en eventos (EDA) suele articularse alrededor de tres componentes.
Productores de eventos
Los productores o publishers son las aplicaciones o servicios que detectan un cambio significativo y publican el evento correspondiente.
Un productor debería limitarse a expresar qué ha ocurrido, sin depender de qué sistemas van a reaccionar después.
Consumidores de eventos
Los consumidores o subscribers reciben o leen determinados tipos de eventos y ejecutan una lógica como respuesta.
Varios consumidores pueden reaccionar de formas completamente diferentes al mismo evento.
Broker, canal o plataforma de eventos
Es la infraestructura encargada de transportar y distribuir los eventos desde los productores hasta los consumidores.
Dependiendo de la arquitectura, también puede proporcionar capacidades de:
- persistencia,
- ordenación,
- reintentos,
- filtrado,
- particionado,
- escalabilidad,
- reproducción de eventos.
Tecnologías como Apache Kafka, RabbitMQ o AWS EventBridge responden a necesidades diferentes dentro de este espacio.
Conoce más sobre nuestra tecnología Confluent Kafka
Pub/Sub y Event Streaming: ¿son lo mismo?
No. Aunque ambos modelos permiten desacoplar productores y consumidores, Pub/Sub y Event Streaming responden a necesidades diferentes.
| Característica | Publish/Subscribe | Event Streaming |
| Objetivo principal | Distribuir mensajes a uno o varios suscriptores | Mantener y procesar un flujo continuo de eventos |
| Persistencia | Depende del broker y de su configuración | El log persistente es una característica central |
| Consumo histórico | Puede ser limitado según la tecnología | Los consumidores pueden volver a leer eventos anteriores |
| Procesamiento | Centrado en recepción y reacción | Centrado en flujos continuos y secuencias de eventos |
| Casos habituales | Notificaciones, mensajería, fan-out | Analítica en tiempo real, integración de datos, ML, auditoría y procesamiento continuo |
Por eso no conviene elegir una tecnología únicamente porque soporte eventos.
La decisión debe partir de cuestiones como:
- ¿Necesitamos conservar el historial?
- ¿Es necesario reproducir eventos?
- ¿Qué volumen debemos procesar?
- ¿Qué garantías de entrega necesitamos?
- ¿Importa el orden?
- ¿Cuántos consumidores existirán?
- ¿Necesitamos procesamiento en tiempo real?
Ventajas de una arquitectura basada en eventos (EDA)
La adopción de la EDA puede aportar ventajas importantes cuando existe una necesidad real de desacoplamiento, escalabilidad o procesamiento en tiempo real.
Menor acoplamiento entre sistemas
El productor no necesita conocer a cada consumidor.
Esto permite añadir nuevos consumidores sin modificar necesariamente el servicio que originó el evento.
Escalabilidad independiente
Los componentes pueden escalar de forma independiente según su carga.
Si aumenta drásticamente el número de pedidos, por ejemplo, pueden ampliarse los consumidores responsables del procesamiento sin tener que escalar todo el ecosistema.
Mayor resiliencia
El desacoplamiento ayuda a aislar fallos.
Si un consumidor deja temporalmente de estar disponible y la infraestructura conserva los eventos, puede procesarlos posteriormente sin detener necesariamente al productor.
Respuesta en tiempo real
Los eventos permiten reaccionar rápidamente a cambios relevantes.
Esto resulta especialmente útil en:
- detección de fraude,
- mantenimiento predictivo,
- IoT,
- personalización,
- monitorización,
- logística,
- analítica en tiempo real.
Mayor agilidad y extensibilidad
Un evento puede generar inicialmente dos reacciones y, con el tiempo, incorporar nuevos consumidores.
Esto permite evolucionar capacidades sin modificar constantemente las integraciones existentes.
Integración entre sistemas heterogéneos
EDA puede servir como mecanismo de conexión entre microservicios, aplicaciones cloud, sistemas legacy y plataformas de terceros, evitando multiplicar las integraciones punto a punto.
Conoce nuestro artículo: ¿Qué son los Microservicios?
¿Qué relación existe entre microservicios y Event-Driven Architecture?
Las arquitecturas basadas en eventos y los microservicios suelen utilizarse conjuntamente porque EDA facilita que los servicios mantengan un mayor grado de independencia.
En una arquitectura basada únicamente en llamadas síncronas, un microservicio puede terminar dependiendo de varios servicios externos para completar una operación.
Los eventos permiten reducir algunas de esas dependencias.
Por ejemplo, el servicio de pedidos puede publicar que el pedido ya está completado, y continuar su ejecución sin necesitar conocer directamente los servicios de inventario, logística, marketing o analítica que reaccionarán después.
Sin embargo, usar microservicios no obliga a utilizar EDA ni utilizar EDA exige disponer de microservicios. Son conceptos complementarios, no equivalentes.
Te podría interesar: Comunicación entre microservicios: Métodos, tipos y estilos
Casos de uso de una arquitectura basada en eventos
EDA resulta especialmente útil en procesos en los que diferentes sistemas deben reaccionar rápidamente ante un cambio.
Banca y FinTech
La detección de una transacción potencialmente fraudulenta puede generar diferentes procesos en paralelo:
- analizar el riesgo,
- bloquear temporalmente una tarjeta,
- alertar al cliente,
- informar al equipo de seguridad.
Retail y e-commerce
Eventos como que el producto se ha visto, que la compra se ha completado o que el stock se ha actualizado pueden utilizarse para:
- actualizar inventario,
- activar procesos logísticos,
- personalizar recomendaciones o,
- actualizar sistemas analíticos.
Industria e IoT
Los sensores generan continuamente eventos relacionados con temperatura, vibración, presión o estado de una máquina.
El procesamiento de estos eventos permite identificar anomalías y alimentar modelos de mantenimiento predictivo.
Logística
Cada cambio de estado de un paquete puede generar un evento.
Esto permite actualizar el seguimiento para el cliente, alimentar sistemas operativos y reaccionar ante retrasos o incidencias.
Sincronización de datos
Un cambio producido en una aplicación puede publicarse como evento para que otros sistemas actualicen su información.
Este modelo puede reducir la necesidad de consultas periódicas o integraciones punto a punto.
Analítica y procesamiento en tiempo real
Los streams de eventos permiten alimentar sistemas analíticos mientras los datos se están produciendo, en lugar de esperar exclusivamente a procesos batch posteriores.
¿Cuándo NO utilizar una arquitectura basada en eventos?
EDA no es la solución adecuada para todos los problemas.
Introducir asincronía, brokers, esquemas, reintentos, observabilidad y procesamiento distribuido implica también mayor complejidad operativa y arquitectónica.
Procesos síncronos sencillos
Si un servicio necesita pedir un dato concreto a otro y obtener inmediatamente una respuesta, una API síncrona puede ser considerablemente más sencilla.
Por ejemplo, determinadas validaciones de identidad o consultas puntuales no necesitan convertirse en eventos.
Sistemas pequeños y estables
Si una aplicación tiene pocos componentes y apenas existe necesidad de escalarlos o evolucionarlos de forma independiente, introducir una plataforma de eventos puede añadir más complejidad de la que elimina.
Procesos que necesitan consistencia inmediata
En determinados procesos transaccionales puede ser necesario conocer el resultado de varias operaciones antes de continuar.
Esto no impide utilizar EDA, pero obliga a diseñar cuidadosamente la consistencia, compensaciones y gestión de estados. En escenarios sencillos, un modelo síncrono puede resultar más adecuado.
Cuando la organización no está preparada para operar sistemas distribuidos
Una arquitectura Event-Driven exige:
- observabilidad,
- gobierno,
- gestión de esquemas,
- manejo de errores,
- monitorización,
- capacidad operativa.
Adoptar Kafka o cualquier otra plataforma no resuelve por sí solo estos aspectos.
Riesgos y errores habituales en arquitecturas Event-Driven
Generar eventos para todo
No cada modificación técnica necesita convertirse en un evento empresarial.
Un exceso de eventos aumenta el ruido, dificulta comprender el flujo y genera dependencias innecesarias.
Los eventos deberían representar hechos suficientemente significativos para otros consumidores.
Ignorar duplicados y reintentos
Los consumidores deben estar preparados para situaciones como:
- procesamiento repetido,
- errores temporales,
- reintentos,
- eventos que llegan más tarde de lo esperado.
Diseñar consumidores idempotentes y definir políticas claras de reintento ayuda a reducir estos problemas.
No definir contratos y esquemas
El desacoplamiento no significa ausencia de contrato.
Productores y consumidores siguen necesitando compartir una definición común del evento.
Esquemas mediante Avro, JSON Schema o especificaciones como AsyncAPI pueden ayudar a establecer esa estructura y controlar su evolución.
No gestionar correctamente las versiones
Cambiar el formato de un evento puede afectar simultáneamente a muchos consumidores.
Por eso es necesario establecer desde el principio reglas de compatibilidad, versionado y evolución de esquemas.
No disponer de suficiente observabilidad
En una llamada síncrona resulta relativamente sencillo seguir el recorrido de una petición.
En una arquitectura distribuida y asíncrona, una operación puede desencadenar múltiples eventos y servicios.
Herramientas y estándares como OpenTelemetry pueden ayudar a construir trazabilidad distribuida y relacionar lo que sucede entre los distintos componentes.
Cómo implementar una arquitectura basada en eventos
1. Empieza con un caso de uso acotado
No transformes todo el core empresarial en el primer proyecto.
Selecciona un proceso que genere valor pero cuyo riesgo sea manejable, por ejemplo:
- notificaciones,
- replicación de información,
- actualización de un dashboard,
- sincronización entre dos aplicaciones.
Esto permite validar arquitectura, tecnología y capacidades operativas antes de escalar el modelo.
2. Diseña los eventos desde el dominio de negocio
Un evento debería reflejar algo significativo que ya ha sucedido.
“Pedido completado” suele expresar mejor el dominio que algo excesivamente técnico como “Campo Estado Pedido Actualizado”
La calidad del modelo de eventos condicionará buena parte de la mantenibilidad posterior de la arquitectura.
3. Define gobierno desde el principio
Establece:
- responsables de los eventos,
- criterios de nomenclatura,
- esquemas,
- compatibilidad,
- versionado,
- documentación,
- políticas de retención,
- gestión de errores.
Un catálogo de eventos permite además que los equipos descubran eventos existentes antes de crear otros nuevos.
4. Diseña la estrategia de errores
Debes decidir qué sucede cuando un consumidor no puede procesar un evento.
Entre las posibilidades se encuentran:
- reintentos,
- backoff,
- dead letter queues,
- alertas,
- reprocesamiento.
No debería dejarse este diseño para cuando aparezcan los primeros errores en producción.
5. Planifica la observabilidad
Una plataforma de eventos debe proporcionar visibilidad sobre:
- throughput,
- latencia,
- consumer lag,
- errores,
- disponibilidad,
- eventos no procesados.
A esto debe añadirse trazabilidad para poder seguir procesos de negocio distribuidos entre diferentes servicios.
6. Planifica la convivencia con la arquitectura actual
Pocas organizaciones parten de cero.
EDA y ESB/SOA no son necesariamente excluyentes.
Un ESB puede actuar como productor o consumidor de eventos y permitir que aplicaciones legacy formen parte progresivamente de una arquitectura más distribuida.
Otro enfoque es el patrón Strangler Fig, que permite sustituir gradualmente capacidades de un monolito mediante nuevos componentes mientras ambos modelos conviven durante la transición.
Esta es precisamente una de las áreas donde un enfoque pragmático resulta más importante, adoptar EDA no significa rediseñar toda la organización alrededor de eventos.
No te pierdas nuestro nuevo artículo: Modernización continua: cómo mantener legacy y microservicios en sincronía cuando el negocio evoluciona
7. Elige la tecnología según el problema
No toda arquitectura Event-Driven necesita Kafka.
Dependiendo del escenario:
- Apache Kafka o Confluent: event streaming, alto throughput, persistencia y replay,
- RabbitMQ: mensajería, colas y procesamiento asíncrono,
- AWS EventBridge, Google Cloud Pub/Sub o Azure Event Grid: arquitecturas cloud y servicios gestionados,
- Apache Flink: procesamiento y análisis avanzado de streams.
La decisión debe partir del caso de uso, el volumen, las garantías requeridas, las competencias disponibles y la arquitectura existente.
Arquitectura Event-Driven y sistemas legacy: ¿hay que sustituirlo todo?
No. Una organización puede incorporar capacidades basadas en eventos de forma progresiva sin sustituir inmediatamente sus sistemas existentes.
Aplicaciones legacy, ESB y plataformas modernas pueden actuar como productores o consumidores mientras determinadas capacidades se trasladan gradualmente a nuevos servicios.
Este planteamiento permite utilizar EDA donde realmente aporta valor y mantener modelos síncronos o arquitecturas existentes allí donde siguen siendo adecuados.
En Chakray trabajamos la arquitectura basada en eventos como una capacidad dentro de una estrategia de integración más amplia, no como un objetivo en sí mismo.
Nuestro equipo puede ayudarte a identificar qué procesos se benefician realmente de EDA, elegir la tecnología adecuada y diseñar una hoja de ruta que permita convivir con APIs, sistemas legacy, microservicios y entornos cloud.
Si estás evaluando una arquitectura Event-Driven o quieres evolucionar una implementación existente, ¡contacta con nuestro equipo y cuéntanos tu escenario!
Preguntas frecuentes sobre arquitectura basada en eventos
¿Qué es una arquitectura basada en eventos?
Una arquitectura basada en eventos o Event-Driven Architecture (EDA) es un modelo en el que los sistemas se comunican generando y consumiendo eventos que representan hechos o cambios de estado.
¿Cómo funciona una arquitectura Event-Driven?
Un productor genera un evento, lo publica a través de un broker o canal y uno o varios consumidores lo reciben o leen para ejecutar acciones de forma independiente.
¿Cuál es la diferencia entre Pub/Sub y Event Streaming?
Pub/Sub está orientado principalmente a distribuir mensajes entre publicadores y suscriptores. Event Streaming se basa normalmente en un flujo persistente de eventos que puede almacenarse, procesarse y volver a consumirse.
¿Qué ventajas tiene una arquitectura basada en eventos?
Sus principales ventajas son el desacoplamiento entre sistemas, la escalabilidad independiente, la resiliencia, la capacidad de respuesta en tiempo real y la facilidad para incorporar nuevos consumidores.
¿Cuándo debería utilizarse una arquitectura Event-Driven?
Tiene especial sentido cuando varios sistemas necesitan reaccionar a cambios, existen grandes volúmenes de datos, se requiere procesamiento en tiempo real o los componentes deben evolucionar y escalar de forma independiente.
¿Puede una arquitectura basada en eventos convivir con sistemas legacy?
Sí. Los sistemas legacy pueden actuar como productores o consumidores de eventos y convivir con nuevos componentes durante una modernización gradual.
¡Habla con nuestros expertos!
Contacta con nuestro equipo y descubre las tecnologías de vanguardia que potenciarán tu negocio.
contáctanos
