De la misma forma que cuando trabajamos con cualquier arquitectura tenemos algunos estándares, en la Arquitectura Dirigida para Eventos no sería diferente. Así, tenemos 3 estándares principales, que son: Event Notification, Event Carried State Transfer y Event Source. ¿Vamos a conocer un poco más sobre ellos? 

Event Notification

Cuando trabajamos utilizando Event Notification, el sistema enviará notificaciones para otros sistemas sobre una modificación que ocurrió en su dominio, en el caso que alguno de los sistemas que recibieron la notificación tenga interés en saber más sobre la modificación, él deberá ir a una interfaz suministrada por el proveedor para captar más informaciones. 

También usaremos el ejemplo del artículo anterior (Si no lo leíste, corre que aún da tiempo, él está disponible en este enlace), que es el cambio de dirección de un cliente, pero ahora, piense conmigo en un caso hipotético de mercado (que puede ser real, acepto royalties), un marketplace de ventas compartirá los datos de registro de sus clientes con colaboradores de mercado, entre ellos, bancos, esto será útil principalmente para actualizaciones relacionadas a informaciones de dirección, una vez que es más fácil actualizar mi dirección en un marketplace donde recibiré el nuevo producto que compré, en lugar de acordarme de actualizar el banco. Con este ejemplo en mente, vamos para nuestro caso de uso utilizando Event Notification:

El cliente modificará su dirección, el Servicio de clientes será responsable de actualizar las informaciones en la base de datos y de disparar una notificación de evento con el mensaje “Cliente 43F31A1 actualizó los datos” para el broker, los servicios que están interesados en informaciones de aquel sistema específico estarán escuchando y si, por ejemplo, el servicio bancario reconoce al cliente y tiene interés en sus datos actualizados, él hará una llamada al servicio de clientes, como GET/clientes/43F31A1 para recuperar las informaciones y actualizar sus datos. En el caso que el servicio bancario no conozca al cliente en cuestión, él simplemente ignorará el mensaje. 

Al utilizar este estándar, tenemos la ventaja del bajo acoplamiento, pues separamos al receiver del sender y, como desventaja, podemos tener la sobrecarga del productor, una vez que puede haber N sistemas que están interesados en la actualización y pueden ir al mismo tiempo a buscar más informaciones sobre la misma en el productor.

Event Carried State Transfer 

Utilizaremos Event Carried State Transfer cuando tengamos la necesidad de enviar la información completa en el mensaje, de esta forma los procesadores no deberán consultar al productor para saber cuáles fueron los cambios. 

En nuestro ejemplo, el cliente modificará su dirección y el Servicio de clientes será responsable de actualizar las informaciones en la base de datos y de disparar una notificación de evento, pero en lugar de decir solamente que el cliente 43F31A1 actualizó los datos, él enviará el mensaje con los datos completos, como en el caso del cambio del Código Postal, el mensaje debe ser “Cliente 43F31A1 actualizó el Código Postal para 29580000”, y con esto, los procesadores tendrán la información completa para realizar su trabajo. El procesador puede almacenar las informaciones en una base de datos local, para que, al realizar procesamientos futuros, no necesite consultar informaciones en el productor, que en nuestro caso es el servicio de clientes.

Al utilizar este estándar, ganamos resiliencia, una vez los procesadores serán capaces de funcionar, aunque el productor esté indisponible, reduciremos también la latencia, ya que no tendremos la necesidad de ir al productor para obtener más informaciones, y como ustedes ya deben haber percibido, una de las ventajas también es que ya no sobrecargaremos el sistema productor, pues el mensaje contiene toda la información necesaria. 

Como desventajas podemos citar la replicación de las informaciones, y el hecho de que el procesador debe preocuparse con la consistencia de los datos, ya que ahora él también es poseedor de la información.

Event Source

Utilizamos Event Source cuando tenemos la necesidad de almacenar los cambios que ocurren en el estado de un sistema, en cada modificación almacenaremos la modificación como un evento, y cuando sea necesario será posible reconstruir el estado del sistema con confianza, realizando la reprocesamiento de los eventos. 

Siguiendo nuestro ejemplo, el cliente modificará su dirección y el Servicio de clientes será responsable de actualizar las informaciones en la base de datos y de enviar el evento de cambio de dirección, que será almacenado juntamente con los datos que fueron modificados, en un repositorio o base de datos. Si en algún momento nuestro servicio de clientes es borrado, por ejemplo, tendremos el Event Data Source que nos posibilitará la reconstrucción hasta el momento en que estaba.

Al utilizar Event Source, ganamos el audit, en el caso que yo necesite saber qué ocurrió y cuándo ocurrió, puedo hacer una consulta en mi repositorio y descubrirlo. También tenemos el beneficio de poder realizar el debug, que es un punto delicado cuando estamos trabajando con orientación para eventos, si surge la necesidad de realizar el debug del sistema, podemos apuntar nuestro ambiente de pruebas para el repositorio y realizar todas las validaciones que son necesarias. 

Como desventajas podemos citar que Event Source aún no es muy utilizado en el mercado, lo que puede dificultar a la hora de encontrar materiales que aborden el tema, y tenemos también Event Schema, que se refiere a lo que almacenaremos en el repositorio. ¿Será todo evento que ocurra? ¿Solamente los eventos que llegan? Debemos escoger bien cuál esquema seguiremos en el momento de almacenar las informaciones. 

Bien, estos son 3 de los estándares que tenemos en la arquitectura dirigida para eventos, ¿usted ya trabajó con alguno de ellos? ¿Cuál fue tu experiencia? ¡Cuéntanos!

Y estén atentos, muy pronto tendremos un artículo hablando sobre la documentación de las interfaces asíncronas, AsycAPI.