Eventos
9
min de lectura
30 de septiembre de 2019

Comprensión de Event Driven

Ana Paula Borges
Jefe de Tecnología de Innovación de Ventas @Ambev
Diseño de la API siguiendo los conceptos de RESTFull. Desarrollo de API en JavaScript, Java. Desarrollo de Microservicios en Java. Desarrollo de integraciones en IIB Broker. Modelado de servicios para el protocolo SOAP. Desarrollo de sistemas en Graphql.
Más sobre el autor

Cuando trabajamos con cualquier arquitectura, tenemos algunos estándares. Con Event Driven Arquitectura no es diferente. Por lo tanto, tenemos 3 patrones principales, que son: Notificación de eventos, transferencia de estado de eventos y fuente de eventos. ¿Qué hay de saber un poco más sobre ellos?  

Notificación de eventos

Cuando trabajamos con Notificaciones de Eventos, el sistema enviará notificaciones a otros sistemas sobre un cambio que se ha producido en su dominio, en caso de que alguno de los sistemas que recibe la notificación esté interesado en conocer más sobre el cambio, deberá acudir a una interfaz proporcionada por el proveedor para capturar más información.

Seguiremos utilizando el ejemplo del artículo anterior (si aún no lo has leído, aún estás a tiempo, ya que está disponible en este enlace), que es el cambio de dirección de un cliente, pero ahora, piensa en mí en un caso hipotético de mercado (que puede ser real; acepto los derechos de autor), un marketplace de ventas compartirá sus datos maestros de clientes con los socios del mercado, incluidos los bancos. Esto será especialmente útil para las actualizaciones relacionadas con la información de la dirección, ya que es más fácil para mí actualizar mi dirección en un marketplace donde recibiré el nuevo producto que he comprado, en lugar de acordarme de actualizar el banco. Con este ejemplo en mente, vayamos a nuestro caso de uso utilizando la Notificación de Eventos.

Los clientes cambiarán de dirección, los centros de atención al cliente se encargarán de actualizar la información en la base de datos y de activar una notificación de evento con el mensaje "Datos actualizados del cliente 43F31A1" a su corredor, los centros de servicio que apuntan a la información de ese sistema estarán a la escucha y si, por ejemplo, el servicio bancario reconoce al cliente y está interesado en sus datos actualizados, hará una llamada a los centros de atención al cliente como GET/customers/43F31A1 para recuperar la información y actualizar sus datos. Si el servicio bancario no conoce a los clientes en cuestión, simplemente ignorará el mensaje. Al utilizar esta norma, tenemos la ventaja de un bajo acoplamiento, ya que separamos el receptor del emisor y como desventaja podemos tener los gastos generales del productor, ya que puede haber N sistemas que estén interesados en la actualización y, al mismo tiempo, pueden buscar más información al respecto con el productor.

Transferencia del estado del evento llevado a cabo

Utilizaremos la Transferencia de Estado de Eventos cuando tengamos que enviar la información completa en el mensaje, así los procesadores no necesitarán referirse a un productor para saber cuáles fueron los cambios.

En nuestro ejemplo, los clientes cambiarán su dirección y el centro de atención al cliente se encargará de actualizar la información en la base de datos y lanzar una notificación de evento, pero en lugar de limitarse a decir que el cliente 43F31A1 ha actualizado los datos, enviará el mensaje con los datos completos; como en el caso del cambio de código postal, el mensaje debería ser "El cliente 43F31A1 ha actualizado el código postal a 29580000", y con ello, los procesadores tendrán la información completa para realizar su trabajo. El procesador puede almacenar la información en una base de datos local, de modo que cuando realice el procesamiento posterior, no necesite consultar la información con el productor, que, en nuestro caso, es el centro de atención al cliente.

Al utilizar esta norma, ganamos en resiliencia, ya que los procesadores podrán funcionar incluso si el productor no está disponible. También reduciremos la latencia, ya que no tendremos que acudir al productor para obtener más información, y como ya habrás notado, una de las ventajas es que tampoco sobrecargaremos el sistema del productor, porque el mensaje contiene toda la información necesaria.

Los contras son la replicación de la información y el hecho de que el procesador debe preocuparse por la coherencia de los datos, ya que ahora también posee información.

Fuente del evento

Utilizamos la fuente de eventos cuando necesitamos almacenar los cambios que se producen en el estado de un sistema. Con cada cambio, almacenaremos la modificación como un evento y, cuando sea necesario, será posible reconstruir el estado del sistema con confianza, reprocesando así los eventos.

Según nuestro ejemplo, el cliente cambiará su dirección y el Centro de Atención al Cliente se encargará de actualizar la información en la base de datos y enviar el evento de cambio de dirección, que se almacenará junto con los datos modificados, en un repositorio o base de datos. Si en algún momento nuestro servicio de atención al cliente es eliminado, por ejemplo, dispondremos de una fuente de datos de eventos que nos permitirá reconstruirlo, de forma que pueda quedar como antes.

Utilizando la fuente de eventos, obtenemos la auditoría. Si quiero saber qué ha pasado y cuándo ha ocurrido, puedo consultar mi repositorio y averiguarlo. También nos beneficiamos de poder depurar, que es un punto complicado cuando trabajamos con la orientación a eventos. Si uno necesita depurar el sistema, puede apuntar el entorno de pruebas al repositorio y realizar todas las validaciones que sean necesarias.

Como desventajas podríamos mencionar que la Fuente de Eventos aún no está muy extendida en el mercado, lo que puede dificultar la búsqueda de materiales que aborden el tema.

Además, también tenemos el esquema de eventos, que se refiere a lo que almacenaremos en el repositorio. ¿Tendrán lugar todos los eventos o sólo los próximos? Tenemos que elegir adecuadamente qué esquema vamos a seguir al almacenar la información.

Bueno, estos son 3 de los estándares que tenemos en la arquitectura orientada a eventos. ¿Has trabajado con alguno de ellos? ¿Cómo fue tu experiencia? Háganoslo saber! Y permanezca atento. Pronto publicaremos un artículo sobre la documentación de las interfaces asíncronas, concretamente AsycAPI.

¡Gracias por leer!