Las arquitecturas basadas en eventos (EDA) son 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.

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 en el caso que se desea averiguar qué sucedió en el pasado, se puede volver atrás y reproducir el registro.

Cuando se utiliza una arquitectura basada en eventos, existen productores de eventos que generan y envían notificaciones de eventos pudiendo haber uno o más consumidores de un evento, donde la recepción del evento activa la lógica de procesamiento. Por ejemplo, Netflix acaba de subir una nueva película. Podrían haber varias aplicaciones escuchando o esperando esa notificación que luego activarán los propios sistemas internos para publicar su propia información sobre ese evento a sus usuarios.

En ST tenemos un grupo humano de especialistas que cuenta con los conocimientos necesarios para hacer una implementación y uso del servicio de arquitecturas even drivers de manera exitosa y segura. Nuestro principal objetivo es ayudar a nuestros clientes a que éstos puedan saltar de un modelo centrado en datos a un modelo centrado en eventos, lo cual en términos simples podría ser la capacidad de tener un microservicio que se encarga de procesar los pagos de los clientes y otro que se encarga de gestionar el inventario de productos. Cuando un cliente realiza una compra, el microservicio de pagos generaría un evento que notificaría al microservicio de inventario que se ha vendido un producto en particular. El microservicio de inventario actualizaría entonces su base de datos para reflejar el cambio en el inventario. De esta manera, cada microservicio puede funcionar de manera independiente y escalable, lo que hace que la aplicación en su conjunto sea más robusta y escalable.