Introducción a las arquitecturas dirigidas por eventos

Imagina que trabajas en una empresa de logística de terrestre, en la que se generan constantemente situaciones a las que debes darle cierta prioridad o actuar en consecuencia. Dicha empresa tiene en promedio 10,000 tracto-camiones recorriendo toda América Latina 24/7 365 días del año.

Un día, te piden un nuevo requerimiento para la plataforma existente. Este requerimiento se basa en una política en la que ningún conductor que esté transportando mercancía puede ir a más de 80 km/h por lo que si detectamos a alguien que sobrepase esa velocidad, hay que enviarle una notificación al conductor para que la reduzca.

¿Cómo creamos software que pueda reaccionar ante esta cantidad masiva de eventos y darles una respuesta adecuada?

Los eventos

Este ejemplo nos sirve para definir varios conceptos interesantes relacionados con las arquitecturas dirigidas por eventos, la cual es una solución de software (y también de hardware) que reacciona en tiempo real ante el aviso de un evento, ejecutando una determinada acción.

Bueno y a todo esto, ¿qué es un evento? En nuestro ejemplo, es un tracto excediendo el límite de velocidad. Pero a nivel teórico es cualquier cosa que ocurre en un punto concreto del tiempo y que requiere de atención. Puede venir de cualquier lugar de nuestra solución y ocurre asíncronamente. De hecho, la cantidad y el tiempo entre un evento y otro generan un flujo: un streaming o flujo de datos.

Streaming de datos

Estos flujos los conocemos bastante bien en nuestra vida diaria y se generan desde miles de fuentes. Como la información de redes sociales que vemos todos los días, las operaciones bancarias que hacemos o los datos que generan ciertos sensores... ¡Cómo en nuestro caso hipotético del tracto-camión!

Súper fácil y en nuestro ejemplo lo tenemos claro:

• Nuestro streaming de datos lo generan los 10,000 tracto-camiones usando un GPS.
• Los datos, la velocidad del tracto-camión
• Nuestro evento, el exceso de velocidad.
• Nuestra reacción: la notificación desde la central de tráfico para que haga la reducción.

Event processing Frameworks

Ahora, ¿que pasaría si existieran más eventos que quisiéramos tratar? Por ejemplo, que el tracto se detenga en un lugar indebido o antes de llegar a su destino. Ahí es donde entran los event processing frameworks los cuales nos ayudan a trabajar con toda esta información, procesarla y hacer algo con ella. Estas herramientas soportan varios modelos:

• Streaming: Son publicados en un log principal y ordenados conforme suceden. Los consumidores (que pueden ser un API o un dispositivo) pueden leer cualquier parte del log, pero son responsables de mantener el seguimiento de los mensajes que ya procesaron. El event stream o también llamado secuencia de eventos es un flujo constante de eventos, ordenados por tiempo.
• Modelo publicador-suscriptor/consumidor: ¡Así es!, como el patrón de diseño. Aquí un broker o agente mantiene el seguimiento de las suscripciones y cuando un evento es publicado (un tracto que alcanza el máximo de velocidad) lo envía a cada uno de los suscriptores. Los eventos aquí no son guardados, ni pueden reenviarse y los nuevos suscriptores no pueden ver eventos antiguos.

Bueno, y ahora ¿cómo proceso los eventos?

Para ello existen dos "tipos" de procesado. El simple y el complejo (como este post con tanta teoría 😅)

• Simple: Cuando llega un evento, desencadena una acción en el consumidor. Esta acción tiene una lógica simple y se basa enteramente en el contenido del evento.
• Complejo: Este procesamiento en el consumidor puede o no procesar una serie de eventos y realizar análisis de patrones más sofisticados para detectar correlación o causalidad. Por ejemplo, fraude o análisis de sentimientos en un texto.

Ya tenemos identificada cada parte de la arquitectura... ahora, ¿cómo creamos una solución?