Sagas: Realizando Transações com Resiliência

Uma saga é um algoritmo capaz de coordenar várias mudanças de estados, mas que evita a necessidade de travar recursos por longos períodos. Uma saga, faz isso modelando os passos envolvidos na forma de atividades discretas que podem ser executadas de forma independente.

Quando se usa uma saga, nos forçamos a modelar explicitamente os processos de negócio , podendo cada processo representar diversas chamadas independentes que colaboram entre si.

Modos de falha

Em uma saga, sabemos a natureza individual de cada processo, portanto precisamos lidar com as falhas destes processos, o artigo original nos descreve dois tipos de recuperação

• Backward Recovery

  • É a recuperação por retrocesso, se dedica a reverter a falha e fazer uma limpeza, como um rollback. Para que ela funcione, é necessário definir ações compensatórias que nos permitem desfazer as transações cujo o commit já foi feito. Por exemplo, para uma falta de estoque, uma ação compensatória seria o cancelamento do pedido.

• Forward Recovery

  • É a recuperação por avanço, nos permite prosseguir da etapa que falhou e continuar o processamento. Para que ela funcione, é necessário que seja possível retentar uma transação dentro da saga, além disso, precisamos também persistir algumas informações que nos habilitem saber qual processo precisa realizar a retentativa.

Rollback de sagas

Se quisermos implementar um rollback, teremos que implementar, na verdade, uma transação compensatória destinada a cada passo da saga, ao qual o commit já tenha sido feito.

Entretanto, é importante notar que o rollback da saga jamais atingirá a mesma efetividade de um rollback ACID, feito em um banco de dados, pois o rollback de banco de dados é feito antes do commit ser escrito, no cenário das sagas o rollback é uma ação reversiva, apenas uma reação a primeira escrita já feita.

Como nem sempre conseguiremos reverter o rollback em sagas, costuma-se chamar rollback semânticos.

Uma vez que nem todo problema tem natureza igual e irreversível, é recomendado combinar os dos tipos de rollback semântico, backward e forward, evitando soluções catastróficas para problemas pequenos, ou assim como dar continuidade a um problema gravissímo irreversível.

Além disso, para cada rollback, lembre-se sempre de persistir informações relacionadas ao que foi feito e seu motivo.

Implementando Sagas

Existem dois tipos de implementação para sagas orquestradas e coreografadas, as orquestradas seguem as referencias ao artigo original, dependem de uma figura central monitorando, além de uma cordenação entre os processos. Todavia as coreografadas seguem um caminho contrário, evitando a necessidade de coordenação centralizada, em favor de menos acoplamento em detrimento a capacidade de monitorar como nas sagas orquestradas.

Sagas Orquestradas

As sagas orquestradas utilizam um coordenador centralizado para definir uma ordem de execução e disparar qualquer ação compensatória necessária.

O orquestrador controla o que acontece e quando acontece; com isso, existe muita visibilidade sobre o que acontece no processo. Em geral, sagas orquestradas tendem a fazer uso intensivo de iterações “request-response” entre os serviços, com o objetivo de garantir o conhecimento sobre sucesso ou falha do processo.

A principal desvantagem do orquestrador é o acoplamento, uma vez que é necessário centralizar e conhecer todos os serviços do fluxo, além de causar um ponto único de falha (SPOF).

Sagas Coreografadas

As sagas coreografadas tem como objetivo distribuir a responsabilidade entre vários serviços que colaboram entre si, fazem uso intensivo de eventos para se comunicar. Conceitualmente um broadcast de eventos é feito no sistema, assim cada parte interessada pode recebe-los conforme o a aplicação de tópicos na arquitetura de eventos.

Supondo um cenário de pedido realizado em um e-commerce, a entidade depósito recebe o primeiro evento e sabe que seu trabalho é realizar uma reserva no estoque, logo após produz um evento da ação, ação está que pode gerar um evento de feito ou não feito.

Ao publicar um desses eventos, as partes interessadas no fluxo de pedido reagirão, por exemplo para o pagamento em caso de sucesso na reserva do estoque, ou para o cancelamento em caso de erro na reserva de estoque.

Caso esse mesmo exemplo fosse estruturado em uma saga orquestrada seria desta forma

Como podemos ver, a vantagem da coreografia é poder paralelizar processos, uma vez que N serviços podem reagir ao mesmo evento. Por sua natureza independente, sem saber dos outros processos cada serviço se concentra apenas na sua própria ação, reduzindo drasticamente o acoplamento e aumentando a distruibuição correta de lógica e responsabilidades.

Bibliografia

• Newman, Sam. Building Microservices: Designing Fine-Grained Systems. O'Reilly Media, 2015.

• Wikipedia contributors. "Single point of failure." Wikipedia, A Enciclopédia Livre, https://en.wikipedia.org/wiki/Single_point_of_failure

• Wikipedia contributors. "Event-driven architecture." Wikipedia, A Enciclopédia Livre, https://en.wikipedia.org/wiki/Event-driven_architecture

• Hector Garcia-Molina & Kenneth Salem. Sagas. Cornell University, 1987. https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf