Si has ido siguiendo el curso, te habrás dado cuenta que la mayoría de transacciones suceden en un único dominio dentro de la arquitectura completa de nuestro sistema.
Pero qué sucede si tenemos que actuar en múltiples dominios? Aquí es donde entra el patrón saga.
1 - Qué es el patrón saga?
El patrón saga es un patrón que utilizaremos para estar seguros de la consistencia en nuestras transacciones cuando estas contienen múltiples microservicios, ya que lo haremos a través de eventos.
En el mundo monolítico esto sería actualizar múltiples tablas dentro de una transacción, pero claro, eso no es posible en los sistemas distribuidos.
Podemos utilizar patrones SAGA creados tanto de forma manual con producers/consumers como “todo en la misma aplicación” ayndandonos de una librería externa. Dependerá, como siempre, de nuestro caso de uso y de la estructura que tengamos.
El punto principal del patrón es que debemos crear estructuras de servicios para los casos en los que todo funciona bien, y para casos donde cada acción falla.
Por ejemplo, siguiendo con el curso de Distribt, tenemos la creación de un pedido, el cual requiere diferentes pasos:
Podemos ver diferentes partes del proceso, donde todo funciona bien, cada una puede ser de un microservicio diferente o del mismo.
Y ahora debemos incluir todos los casos donde algo falla que es donde se empieza a complicar todo un poco.
Como vemos, tenemos diferentes escenarios si algo falla. además en unos casos queremos volver atrás, como en la validación de los productos. Mientras que en otros lo que queremos es reintentar, en otros necesitamos una acción manual. A esta acción se le llama compensar.
2 - Diseñar una saga
Como acabamos de ver, una SAGA consiste en una serie de transacciones que están fuertemente ligadas entre ellas y completan un proceso o un flujo de principio a fin.
Estas transacciones, contienen el happy path cuando todo funciona y una parte que llamamos compensación, que sucede cuando algo falla.
Lo importante aquí es que no dejemos eventos o el proceso a medias. Por lo tanto en nuestro caso vamos a convertir nuestro gráfico anterior a un flujo SAGA:
Como podemos ver, el proceso de lo que en un monolito sería introducir datos en tres tablas se ha complicado, y mucho. Y eso que este flujo está reducido, porque podríamos añadir más pasos para hacerlo perfecto.
Por cada paso hacia delante que damos, tenemos que tener preparados por lo menos uno para atrás, pero lo más probable, es que sean dos o incluso más, ya que o bien tenemos que deshacer lo modificado, o tenemos que alertar para realizar una acción manual y desbloquear el proceso, etcétera.
Además, como ves, estamos utilizando un service bus, que en nuestro caso será RabbitMQ, pero da igual el que utilizemos lo importante es que tenemos que utilizar el patrón productor/consumidor si o si, por lo tanto hay que tener todo muy bien diseñado y pensado.
2.1 - Diseñar una saga en .NET
A la hora de construir una SAGA en tu sistema, simplemente tienes que seguir múltiples todas las pautas y todos los pasos. Pero, cómo has podido imaginar esto es bastante complejo, ya que tenemos que crear handlers para cada evento además de tenerlo todo bien configurado.
Este proceso nos sirve para cualquier lenguaje de programación, es completamente independiente del lenguaje. Pero en .NET tenemos una serie de librerías que nos van a permitir crear Sagas de una forma más sencilla.
En este grupo podemos encontrar librerías como MassTransit, Microsoft Orleans, Rebus, o muchas otras.
En el caso de masstransit o rebus toda la comunicación se basa en el patrón productor/consumidor a través de RabbitMQ; Mientras que Microsoft orleans esta mas centrado en llamadas API. Todas estas librerías lo que hacen es mantener información del estado de la saga para qué, en el caso de que algo no funcione bien, continúe desde ese punto. Digamos que la librería es la que se encarga de asegurarse de que todo se ejecuta, y que no se queda nada a medias en el tintero.
Profesionalmente además de hacer la saga distribuida de forma “manual”, con handlers, la cual es mi forma favorita. He utilizado masstransit en proyectos que ya lo habían introducido con anterioridad.
Y Microsoft Orleans durante una migración de monolito el cual estaba muy entramado en sus dominios a microservicios. Ya que se fue migrando poco a poco y el sistema no estaba preparado para ejecutar el patrón productor/consumidor de una forma eficiente durante dicha transición. Una vez finalizamos la migración, quitamos Orleans, ya que hacíamos todas las sagas de forma “manual”.
Conclusión
En este post hemos visto qué es el patrón saga.
En qué difiere el patrón saga de una transacción en el monolito.
Cómo diseñar una SAGA.
Cómo crear SAGAs en C#.
