La vertiginosa realidad exige a las empresas decisiones inmediatas. En este contexto, emerge el concepto de event driven architectures (EDA) o arquitecturas basadas en eventos. A diferencia de los esquemas tradicionales, los modelos orientados a servicios, donde hacía falta una solicitud para que un sistema elaborara una respuesta, este modelo detecta cualquier “evento” que ocurra y actúa en consecuencia en tiempo real.

¿Qué son los “eventos” que disparan la reacción de los sistemas? Por definición, un evento es un cambio de estado de algún sistema empresarial clave. Esto, llevado a la práctica, puede ser cualquier interacción de un usuario con una aplicación o con el sitio web, una transacción de un cliente en una tienda física o virtual o incluso el cambio de estado de una máquina o de un producto detectado por algún dispositivo de internet de las cosas (IoT) e informado de manera automática.

Eventos y mensajes

Una persona que visita el sitio corporativo, un usuario que abandona un carrito de compras, una maquinaria que está sufriendo un desperfecto, un vehículo de la flota que se desvía de su recorrido esperado, una materia prima que está llegando al umbral de faltante en stock, un paquete que fue entregado en destino, la detección de un ingreso no autorizado a los sistemas, la solicitud de un usuario para restablecer una contraseña…

Los ejemplos de “eventos” son prácticamente infinitos y dependen de la actividad y los intereses de cada organización. Otro detalle: los eventos son omnipresentes en empresas de cualquier industria, de todo tipo y de todo tamaño. Existen en todas partes y ocurren de manera continua. Son inevitables.

Por otra parte, hay que diferenciar “evento” de “mensaje”. El primero es el hecho en sí. El segundo, la notificación de que ocurrió el evento. Cuando se envía la notificación, el sistema “entiende” que se produjo un cambio de estado y evalúa cuál es la respuesta apropiada y quién debe recibirla. La aplicación que recibió ese mensaje puede responder o esperar a responder hasta que se haya producido el cambio en el estado que está esperando.

Por ejemplo, ante la mencionada solicitud de restablecimiento de la contraseña (el evento), el sistema es notificado sobre lo ocurrido (el mensaje) y seguramente el cliente reciba un correo electrónico con las indicaciones a seguir (la respuesta).

Arquitectura EDA: Asincronía y velocidad

En la arquitectura EDA se identifican dos grupos de jugadores: el de los productores y el de los consumidores de eventos. Los primeros son los que generan los eventos que serán notificados a los segundos para activar el procesamiento involucrado en la respuesta.

Una de las características de esta arquitectura es que la comunicación resulta asincrónica: el remitente y el destinatario no necesitan esperar la respuesta de la otra parte para seguir avanzando en su tarea. Esto es fundamental desde el punto de vista de la experiencia del usuario, ya que no sufre demoras ni obstáculos.

Otra diferencia notable respecto de arquitecturas anteriores es que si bien los datos continúan siendo la materia prima clave, la prioridad pasan a ser los eventos. Los modelos orientados a servicios se enfocaban en no “desperdiciar” ningún dato, este, en que ningún evento quede sin responder.

Un cambio cultural importante que viene asociado a la EDA: cuanto más viejo se vuelve un evento, menos valioso resulta. Por eso, es importante asegurarse de que se da respuesta a los eventos en la medida en que van sucediendo. De todas formas, la EDA también utiliza un log de seguimiento que permite identificar qué ocurrió con cada evento, generar métricas de rendimiento y propiciar las herramientas para avanzar sobre una estrategia de mejora continua.

Los cambios se producen a toda velocidad. Las arquitecturas EDA proponen identificarlos rápidamente y gestionarlos con aplicaciones más ágiles, contextuales, receptivas y eficientes.