Basada en arquitecturas guiadas por eventos (Event Driven Architecture), las sagas nos garantizarán la consistencia de datos en las transacciones de negocio que involucren varias transacciones locales entre varios servicios o participantes en un determinado sistema distribuido.

Principalmente gestiona una secuencia de transacciones locales que completarán dicha transacción de negocio: cada transacción local de cada servicio se ejecutará basándose en el resultado de otros participantes o servicios mediante la comunicación de eventos de dominio.

Cada servicio deberá ser responsable de realizar su posible transacción de compensación (rollback) de una transacción local ya realizada correctamente en el caso de algún error reaccionando a los llamados eventos de compensación.

Existen dos tipos de gestión de sagas: basada en orquestación o coreografía.

Choreography

Los participantes reaccionan de forma autónoma. Cada servicio participa en la transacción distribuida de forma individual. Siendo responsable de gestionar su propia transacción local según la operación resultante de otro participante: continuar la saga o ejecutar la transacción de compensación (deshaciendo cambios ya realizados) desencadenando los eventos de compensación. Notificando si la transacción ha sido realizada correctamente o no, publicando el evento correspondiente.

No existe un single point of failure y los servicios se encuentran totalmente desacoplados. Aunque (dependiendo del número de participantes o servicios que colaboren para garantizar la ejecución completa de la transacción distribuida) puede ocasionar un aumento en la complejidad dificultando las tareas de testing, debug y monitoring.

Orchestration

Los participantes son gestionados desde un único punto: el orquestador de la saga. Mediante una primera operación orquesta las llamadas secuenciales al conjunto de participantes para llevar a cabo la transacción de negocio distribuida.

Si el orquestador detecta un error en alguna respuesta en la ejecución de algún participante ejecutará las acciones correspondientes de compensación en cada uno de los participantes ya ejecutados hasta el momento.

Las ejecuciones de los participantes se realizan asíncronamente siguiendo el orden necesario si se requiere. Pueden existir varias posibilidades de implementación dependiendo del stack tecnológico, aunque recomendable usar los patrones Remote Procedure Call (RPC) request/async response o request/replay en las comunicaciones con los participantes.

La ventaja principal es la visibilidad que aporta tener todo el workflow centralizado en el orquestador resultando más sencillas las operaciones de testing, debug y monitoring. Aunque disponemos de un único componente creando una dependencia entre los participantes.

Entonces, si realmente y lo verdaderamente importante en nuestro sistema son los eventos de dominio para mantener la consistencia de los datos, disponiendo además de diferentes estrategias y prácticas que solventan diferentes problemas en el momento que guardamos dichos estados (escritura) y otras cuando necesitamos consultarlos (lectura). La pregunta sería: ¿Porque no trabajamos únicamente con eventos?. Acercándonos así a Event Sourcing y CQRS.

Bajo mi punto de vista, la solución ante un problema dado en una situación y contexto concretos se encuentra en el equilibrio entre los costes y beneficios de cada decisión que tomemos en cada momento. Y las decisiones (si dispones de posibilidad de colaborar o influir en ellas, claro) mejor tomarlas en base a los datos que dispongas y conocimientos/experiencia del equipo. Y recuerda incluir como coste la complejidad que añadas.

Hasta aquí, de momento, los principales patrones que nos permitirán garantizar una consistencia de los datos. Lógicamente estas prácticas tendrán un coste de desarrollo, aunque ya hemos visto que este tipo de prácticas no son nuevas, no hará falta reinventar la rueda: tenemos disponible una gran cantidad de herramientas open source que nos facilitarán implementarlos (incluyendo servicios cloud como las Durable Orchestrations de Azure) basándonos así en patrones y guías comunes siendo más sencillo explicarlos y manteniendo siempre un orden y coherencia en nuestras prácticas.

Feedback is always welcome

Lecturas y charlas recomendadas:

• https://microservices.io/patterns/data/saga.html
• https://medium.com/@ijayakantha/microservices-the-saga-pattern-for-distributed-transactions-c489d0ac0247
• https://jimmybogard.com/life-beyond-distributed-transactions-sagas/

El problema principal, no radica en que una determinada base de datos garantice o no ACID en sus transacciones (lógicamente, debería serlo para minimizar el riesgo de inconsistencias), sino dividir las operaciones de un mismo workflow (creación completa del pedido con todas sus operaciones) en varias transacciones locales independientes entre los diferentes contextos y bases de datos, sean las que sean.  

De modo que garantizar las comunicaciones entre los contextos es vital para permitir las ejecuciones distribuidas entre ellos manteniendo la consistencia de los datos.

Normalmente debemos notificar el evento una vez realizada la transacción local. Para ello, ejecutamos la transacción y a continuación publicamos el evento a nuestro message-broker:

El problema es que la transacción y el envío del evento, no son atómicos: se ejecutan independientemente pudiendo provocar posibles inconsistencias de datos si alguno de ambos falla:

El patrón Transactional Outbox nos permitirá una única transacción atómica garantizando una entrega At-Least-Once y dándonos la posibilidad de reprocesarlos en cualquier momento.

Lo aplicaremos guardando en la misma transacción tanto la operación que deseemos realizar (que garantice ACID), como los eventos que pueda generar. Los eventos quedarán persistidos en la base de datos:

Mediante Polling Publisher publicaríamos los eventos a nuestro message-broker. Manteniendo el estado de los eventos en el outbox comprobando el ACK en el momento de la publicación (asegurando así la recepción del evento). O incluso, el consumidor podría actualizar el evento a procesado correctamente mediante un CorrelationId o MessageId.

Aseguraremos At-least-once/Once-or-more (los mensajes no se perderán, aunque podrían duplicarse). Por ese motivo, nuestros consumidores deberían ser idempotentes (la ejecución de una o varias veces tendrá el mismo resultado).

Existen herramientas interesantes ya desarrolladas que nos permitirán adaptar outbox pattern de forma sencilla:

• https://docs.particular.net/nservicebus/outbox/
• https://github.com/dotnetcore/CAP

Como he comentado, existen motores de bases de datos distribuidas que nos permiten consistencia de datos en sus transacciones (con ciertas penalizaciones de rendimiento):

Azure Cosmos Db nos da la opción de strong consistency (single region/single operation) y garantizando ACID mediante TransactionalBatch. Ofreciéndonos las Change Feed Functions en el que nos notificará de cualquier inserción o actualización de un contenedor específico. Para ello, necesitaremos una colección donde guardaremos el estado de procesado de las notificaciones (lease containers).

De este modo (con algunos matices) podemos acercarnos al patrón outbox de forma sencilla (aunque, idealmente deberíamos crear una colección específica de eventos generados y disponer de un polling publisher):

Para evitar dicha penalización de rendimiento y garantizar la consistencia: podríamos escuchar los eventos generados creando los datos específicos de consulta en alguna otra base de datos o tecnología. Notificando así además a otros servicios (dada la importancia en la consistencia de datos en transacciones de negocio distribuidas como veremos en el siguiente post):

Hasta aquí uno de los patrones más recomendados habitualmente para garantizar el envío de eventos correspondientes a transacciones locales de cada servicio.

Lecturas recomendadas: