Distintos sistemas consumiendo eventos desde un bus

Arquitecturas orientadas a eventos

En esta entrada vamos a ver cómo te pueden ayudar las arquitecturas orientadas a eventos. Este artículo está escrito desde nuestra experiencia trabajando con multinacionales que atienden a cientos de miles de potenciales clientes a la vez creando por día millones de eventos.

Introducción: ¿Qué es un evento?

Lo primero es definir lo básico. Un evento es un hecho relevante que ocurre en un sistema o negocio y que puede ser aprovechado por otros sistemas para actuar de forma automática.
Ejemplos:

  • En una tienda, cuando un cliente paga, se produce un evento de “compra realizada” o múltiples eventos de «modificación de inventario».
  • En un banco, una retirada de dinero es un evento.
  • En logística, cuando un paquete cambia de estado, por ejemplo cuando un repartidor coge el paquete y lo mete en la furgoneta se produce un evento.

Conceptos clave

  • Productor (Producer): Es quien genera el evento y lo publica en un sistema intermedio. Ejemplo: El repartidor al escanear un paquete con su teléfono y meterlo en la furgoneta genera el evento «mercancía en reparto».
  • Consumidor (Consumer): Es quien escucha o recibe el evento y ejecuta una acción en respuesta. Siguiendo con el anterior ejemplo, un sistema de notificaciones de nuestra empresa de logística recibe el evento anterior y notifica al cliente mediante email que su paquete está en reparto.

Beneficios frente a un enfoque tradicional

En un modelo clásico, las tareas se ejecutan en secuencia. Si una se retrasa o falla, todo el proceso se ralentiza.

Con una arquitectura orientada a eventos:

  • Paralelismo: varios sistemas reaccionan a la vez a un mismo evento.
  • Menor acoplamiento: el productor no necesita conocer los consumidores.
  • Escalabilidad independiente: cada componente crece según su carga.
  • Resiliencia: si un consumidor falla, los demás siguen funcionando.
  • Extensibilidad: se añaden nuevos consumidores sin tocar el productor.

Cómo integrar arquitectura de eventos con sistemas legacy

Uno de los grandes beneficios de trabajar con eventos es que puedes modernizar un sistema antiguo sin tocar su código principal.

Si logras que ese sistema legacy publique eventos cuando realiza ciertas operaciones, cualquier sistema moderno puede suscribirse a ellos y añadir nuevas funcionalidades:

  • Notificaciones móviles.
  • Dashboards en la nube.
  • Automatización de procesos.
Sistemas legacy comunicandose con nuevos sistemas mediante eventos

Esto permite innovar sin rehacerlo todo, sin depender del lenguaje o tecnología original del sistema, reduciendo riesgos y acelerando la modernización.

¿Qué es Kafka?

Apache Kafka es una plataforma distribuida y open source para el manejo de eventos en tiempo real.


Fue creada por LinkedIn y hoy es mantenida por la comunidad Apache y empresas como Confluent.

  • Licencia: gratuita y de código abierto.
  • Cómo funciona:
  • Los productores publican eventos en topics.
  • Kafka almacena estos eventos de forma ordenada y duradera.
  • Los consumidores se suscriben a esos topics y procesan la información.
  • Por qué es tan popular:
    • Altísimo rendimiento y baja latencia, capaz de manejar millones de eventos por segundo.
    • Amplia comunidad y soporte: es más fácil encontrar soluciones y documentación.
    • Escalable y fiable para grandes volúmenes.
    • Ideal para extender sistemas existentes y conectar múltiples aplicaciones.

Cuándo usar una arquitectura orientada a eventos (y Kafka)

Casos ideales:

  • Información crítica en tiempo real (saldo bancario, estado de envío, alertas de seguridad).
  • Necesidad de paralelizar acciones y mejorar el rendimiento.
  • Escenarios de escalabilidad y resiliencia.

Cuándo no es la mejor opción:

  • Procesos donde no importa la inmediatez (informes analíticos que se actualizan cada 30 minutos o una vez al día).
  • Cuando la complejidad añadida de eventos no aporta un valor significativo frente a un proceso batch.

Kafka Streams vs Kafka normal

Aunque Kafka Streams ofrece funcionalidades avanzadas (joins, procesamiento con estado), nuestra experiencia ha sido que:

  • La documentación y ejemplos son menos abundantes.
  • La curva de aprendizaje es mayor.
  • Kafka normal es más estable y sencillo de operar en entornos de alta carga.

Por eso, en muchos casos, preferimos Kafka básico para mantener simplicidad y fiabilidad.

Conclusión

Las arquitecturas orientadas a eventos no solo permiten mejorar el rendimiento y la resiliencia, sino que también abren la puerta a modernizar sistemas legacy sin reescribirlos.

Sobre el autor:


Alberto Barranco es el fundador y CEO de Osohub. Lleva desarrollando desde el 2010.

En Osohub creamos software de calidad valiéndonos de nuestra experiencia, el aprendizaje continuo y la Inteligencia Artificial.
Desarrollamos software a medida para grandes compañías nacionales e internacionales.

¿Tienes algo en mente? Hablemos.

En Osohub no solo escribimos código, hablamos el mismo idioma que nuestros clientes.

Diseñamos soluciones entendiendo el negocio que hay detrás, ya sea logística, aviación, finanzas o ventas.

Porque solo así se puede construir software que de verdad funcione.

Escríbenos a hola@osohub.com