¿Qué es la arquitectura basada en eventos?
La arquitectura basada en eventos (EDA) es un patrón de diseño de software que permite a una organización detectar "eventos" o momentos comerciales importantes (como una transacción, visita al sitio, abandono del carrito de compras, etc) y actuar sobre ellos en tiempo real o casi en tiempo real. Este patrón reemplaza la arquitectura tradicional de "solicitud/respuesta" donde los servicios tendrían que esperar una respuesta antes de poder pasar a la siguiente tarea. El flujo de la arquitectura basada en eventos está dirigido por eventos y está diseñado para responder a ellos o realizar alguna acción en respuesta a un evento.
La arquitectura basada en eventos frecuentemente se denomina comunicación "asincrónica". Esto significa que el remitente y el destinatario no tienen que esperar el uno al otro para pasar a su siguiente tarea. Los sistemas no dependen de ese único mensaje. Por ejemplo, una llamada telefónica se considera síncrona o más en la línea de la arquitectura tradicional de "solicitud/respuesta". Alguien lo llama y le pide que haga algo, el solicitante espera mientras el receptor completa la tarea y luego ambas partes cuelgan. Un ejemplo asincrónico podría ser la mensajería de texto. Envía un mensaje y, en algunos casos, ni siquiera sabe a quién se lo está enviando o si alguien está escuchando, pero usted no esperará una respuesta.
La evolución de la arquitectura basada en eventos
En los últimos años, hubo un movimiento de centrarse en los datos en reposo (arquitectura orientada a servicios) a centrarse en eventos (arquitectura basada en eventos). Estamos pasando de acumular datos y lagos de datos a centrarnos en los datos sobre la marcha y realizar un seguimiento de ellos mientras se mueven de un lugar a otro. Tradicionalmente, la mayoría de los sistemas operan en lo que podría considerarse como el modelo centrado en datos donde los mismos son la fuente de la verdad. El cambio a una arquitectura basada en eventos significa pasar de un modelo centrado en datos a un modelo centrado en eventos. En el modelo basado en eventos, los datos siguen siendo importantes, pero los eventos se convierten en el componente más importante. Mientras que en el modelo orientado al servicio, la máxima prioridad era asegurarse de no perder ningún dato. Con la arquitectura basada en eventos, la prioridad es asegurarse de responder a los eventos a medida que ocurren. Debido a que existe una ley de los rendimientos decrecientes cuando se trata de eventos, resulta que cuanto más envejecen, menos valiosos son. Sin embargo, hoy en día, la arquitectura orientada a servicios y la arquitectura basada en eventos frecuentemente se utilizan juntas.
La arquitectura basada en eventos frecuentemente utiliza una analogía de registro para realizar un seguimiento de las cosas. Los analistas hablan de los eventos como cosas inmutables que sucedieron. Y si desea averiguar qué sucedió en el pasado, puede volver atrás y reproducir el registro. Mientras que en el modelo centrado en datos, usted se centra principalmente en el estado de los datos tal como está en el presente. Y luego, la última analogía que utilizan los analistas al describir la diferencia entre las arquitecturas centradas en datos y centradas en eventos es que frecuentemente las comparan entre un depósito de información y un sistema nervioso que transmite mensajes por toda la empresa.
Cuando utiliza una arquitectura basada en eventos, tiene productores de eventos que generan y envían notificaciones de eventos y puede tener uno o más consumidores de un evento, donde la recepción del evento activa la lógica de procesamiento. Por ejemplo, digamos que Netflix acaba de subir una nueva película. Podrían haber varias aplicaciones escuchando o esperando esa notificación que luego activarán sus propios sistemas internos para publicar su propia información sobre ese evento a sus usuarios. Esto difiere de la mensajería tradicional de solicitud-respuesta en donde las aplicaciones aún se están ejecutando y, aunque pueden estar atentas a ese evento, no se paralizarán durante la espera. Y podrán responder cuando se publique el mensaje. Por tanto, muchos servicios se pueden ejecutar en paralelo.
¿Qué es un evento?
Un evento se define como un cambio de estado de algún sistema empresarial importante. Por ejemplo, alguien compra un producto, otra persona se registra para un vuelo o un autobús llega tarde a algún lugar. Y si uno lo piensa, los eventos existen en todas partes y ocurren constantemente, sin importar la industria. Son omnipresentes en cualquier negocio. Esto incluye que todo lo que crea un mensaje al ser producido, publicado, detectado o consumido se considera un evento. El evento es independiente del mensaje, porque si bien el evento es el acontecimiento, el mensaje es la notificación de viaje que transmite el acontecimiento. En la arquitectura basada en eventos, un evento probablemente desencadenará una o más acciones o procesos en respuesta a su acontecimiento. Un ejemplo de un evento podría incluir:
- Solicitud para restablecer una contraseña
- Un paquete que llegó fue entregado a su destino
- Un almacén de comestibles actualiza su inventario
- Se denegó un intento de acceso no autorizado
Es probable que cada uno de estos eventos desencadene una o más acciones o procesos en respuesta. Una respuesta podría ser simplemente registrar el evento con fines de supervisión. Otros podrían ser:
- Enviar al cliente un correo electrónico para restablecer la contraseña
- Se cierra la factura
- Se realiza un pedido de más lechuga (o cualquier material que se esté agotando)
- Se bloquea una cuenta y se notifica al personal de seguridad
Con la arquitectura basada en eventos, cuando se envía una notificación de evento, el sistema capta que sucedió algo, como un cambio de estado, y espera enviar la respuesta a quien la solicite, siempre que lo solicite. La aplicación que recibió ese mensaje puede responder o esperar hasta que se produzca el cambio de estado que está esperando.
Las aplicaciones creadas en torno a una arquitectura basada en eventos permiten aplicaciones empresariales digitales más ágiles, escalables, contextuales y receptivas.
¿Cómo funciona la arquitectura basada en eventos?
Los componentes de una arquitectura basada en eventos pueden incluir tres partes: productor, consumidor, intermediario. El intermediario puede ser opcional, particularmente cuando tiene un solo productor y un solo consumidor que están en comunicación directa entre sí y el productor simplemente envía los eventos al consumidor. Un ejemplo sería un productor que envía solo a una base de datos o almacén de datos para que los eventos se recopilen y almacenen para su análisis. Por lo general, en las empresas, tiene múltiples fuentes que envían todo tipo de eventos con uno o más consumidores interesados en algunos o todos esos eventos.
Veamos un ejemplo. Si usted es distribuidor, es posible que esté recopilando todas las compras que se realizan en todas sus tiendas de todo el mundo. Los está introduciendo en su arquitectura basada en eventos que está atento al fraude, enviándolos a un procesador de tarjetas de crédito o cualquier acción que deba realizarse a continuación. Para un fabricante, tiene todo tipo de datos provenientes de su equipo que le informan sobre la temperatura y la presión para que pueda monitorear estos eventos en tiempo real y tomar acciones como predecir fallas o programar el mantenimiento, dependiendo de lo que le digan los datos.