O que queremos resolver?
Hoje em dia, quando implementamos um novo sistema, buscamos sempre o desacoplamento e responsabilidade única, quebrando nossos microsserviços e dividindo as responsabilidades.
Mas quando estamos falando de uma solução transacional, onde precisamos realizar uma série de ações e garantir a integridade do conjunto inteiro de processos acabamos por trazer uma complexidade gigante para a nossa solução.
O SAGA Pattern vem para nos ajudar nesse tipo de situação, diminuindo a complexidade.
O que é o SAGA Pattern?
Esse padrão arquitetural de projetos propõe uma solução simples para um problema complexo.
Vamos imaginar uma esteira de compra de produtos básica, onde precisamos criar um pedido, formalizar o pedido, efetuar o pagamento, enviar o pedido para separação e enviar esse produto.
Nesse cenário podemos ver que é necessário um passo a passo para conclusão do pedido, o que pode ser trabalhado de várias maneiras, mas que claramente traz uma complexidade, principalmente quando algo der errado no meio do caminho. Imagine que um dos passos a seguir não seja executado com sucesso, seria necessária uma complexidade grande entre as aplicações para tratamento desse erro.
Pense assim, o pedido foi realizado com sucesso, o estoque realizou a separação e liberou para envio, porém o pagamento não foi aprovado.
Para “desfazer esse processo todos os contextos deveriam estar preparados para entender fluxos de erro de todos os outros, ou seja. O estoque deveria saber desfazer o seu trabalho, dado um retorno negativo de pagamento, ou de formalização, e por sua vez deveriam saber tratar erros do estoque ou entre si, e assim por diante, criando uma cadeia de inter-relacionamento complexa.
Agora imagine que amanhã você precise incluir mais um passo ai no meio, você precisaria alterar toda a cadeia e tratamentos de erro/exceção.
Uma maneira de diminuir esse problema é utilizando o SAGA pattern.
Padrão orquestrado
Se utilizarmos o SAGA pattern com o conceito orquestrado, possivelmente teríamos algo parecido com isso.
A criação de um fluxo de execução com um controlador de passo a passo, diminui a complexidade entre os microsserviços e garante a execução da ação de ponta a ponta.
Essa abordagem como qualquer outra tem seus pontos positivos e negativos.
Com esse modelo de trabalho a execução acontece de forma mais controlada e com maior facilidade de rastreamento, o que é bom para aplicações ainda não tão maduras ou processos onde não vale a pena criar algo mais robusto. Porém claramente estamos criando um centralizador, que cruza contextos trazendo uma complexidade de divisão de responsabilidades, sem contar na centralização de código correndo um risco de isso virar um gargalo de implementação no futuro.
Outra forma de implementação fugindo da orquestração é buscar uma implementação coreografada.
Padrão Coreografado
Note que nesse exemplo, não temos mais um local de centralização de comandos, deixando o sistema mais fluido, porém, podemos notar claramente um aumento de complexidade, ainda mais se pensarmos nos casos de erros, esse desenho tende a se complicar mais do que o primeiro. Porém ele diminui a centralização e o cruzamento de responsabilidade.
Conclusão
Eu particularmente não sou um grande fã de nenhuma das abordagens apresentadas, mas em determinados momentos elas fazem sentido, dado a maturidade da aplicação e cenário de implementação. É uma opção mais simples e barata de resolução de responsabilidades compartilhadas, e com garantia de execução de ponta a ponta. Mas caso seu sistema aumente tome cuidado com essa abordagem, ela pode virar um monstro no futuro, portanto fique atento.
Deixe uma resposta