Padrão Saga.

Saga são transações de longa duração que podem ter um grupo de transações que são intercambiáveis e independentes.

Além disso, as transações da Saga existem a ação compensatória ou o famoso “rollback”.

O padrão Saga é muito utilizado em aplicações com Microsserviços ou distribuídas.

Microsserviços e Saga.

Imagine um ecossistema de um microsserviços para um E-commerce.

Dentro desse ecossistema existem 3 Microsserviços: Pedido, Pagamento e Logística.

Sendo 3 serviços independentes que não se conhecem e com a camada de apresentação assíncrona, como fazer em caso de algum Microsserviço falhar ou não ter um resultado esperado?

Por exemplo, eu usuário faço uma compra e a operadora de cartão não aprova minha compra.

Sistematicamente o caso acima seria chamar o microsserviço de pedido, mostrar para o usuário que está aguardando aprovação em seguida chamar o microsserviço de pagamento.

Todo esse processo pode ser orquestrado pela camada de apresentação, mas vamos ter um problema, quem vai avisar o microsserviço de pedido que a compra foi cancelada pelo Microsserviço de pagamento?

Podemos fazer esse processo de compensação dentro dos tratamentos de erro da camada de apresentação, mas não ficaria muito elegante.

Aqui entramos com o padrão Saga para resolver essa problemática.

Entre a camada de apresentação e os Microsserviços entra uma camada de Gateway para orquestrar as chamadas.

Agora podemos fazer todas as operações de forma transacional, caso alguma operação falhe, podemos desfazer e alterar o status do fluxo.

Observe abaixo 3 operações de compra, 1 com sucesso e 2 com falhas:

Repare que mesmo com o desacoplamento dos Microsserviços podemos transacionar as operações.

Claro que esse foi um exemplo mais simples, problemáticas mais complexas podem envolver outras tecnologias como utilização de Queues.

Conclusão.

O exemplo apresentado foi simplista, mas mostra como resolver algumas problemáticas de aplicações com Microsserviços ou distribuídas que necessitam de operações com transações.

Você tem uma aplicação com microsserviços mesmo ou tem uma arquitetura distribuída?

Sabe qual a diferença entre microsserviços e uma arquitetura distribuída?

Se ficou na dúvida, provavelmente está utilizando uma aplicação com arquitetura distribuída achando que está usando uma tecnologia de microsserviços.

Tecnicamente o que é um microsserviço?

Resumindo, Microsserviços são pequenas aplicações independentes que em conjunto resolvem algum problema.

Já em uma Arquitetura distribuída, existem várias máquinas e aplicações interligados em algum ponto e que resolvem um problema.

Para entender melhor esse conceito, observe as imagens abaixo:

Porque aplicações com Microsserviços são melhores que uma Arquitetura distribuída?

Uma analogia que podemos fazer a uma arquitetura distribuída é o jogo Jenga.

Nesse jogo existem vários blocos que formam 1 bloco maior, o objetivo do jogo é que cada jogador remova um desses blocos menores sem danificar a estrutura do bloco todo.

Quando um bloco danifica a estrutura do bloco principal, todo bloco cai.

Seria isso que aconteceria quando uma parte de um sistema com arquitetura distribuída falhasse.

Em uma arquitetura de Microsserviços, isso não acontece ou acontece com menores proporções de problemas, pois cada parte está desacoplado do sistema como um todo.

Um Microsserviço é totalmente desacoplado de outros Microsserviços e não compartilha infraestrutura como banco de dados, servidor de arquivos e container de aplicação.

Quando um dos Microsserviços é desativado, a aplicação continua funcionando.

Isso acontece pois todos os Microsserviços são independentes, sem nenhuma dependências entre eles.

Vantagens e desvantagens utilizando Microsserviços.

As vantagens de se utilizar Microsserviços a uma aplicação distribuída ou monolítica além da apresentada no tópico anterior são:

Escalabilidade: por ser totalmente independente cada componente, escalar a aplicação fica muito fácil;
Liberdade: Cada Microsserviço pode utilizar a tecnologia certa para resolver determinado tipo de problema;
Facilidade na depuração: por ser pequenas aplicações, testar e depurar fica mais fácil do que testar uma grande aplicação;

Mas existem desvantagens também, seguem algumas:

A infraestrutura fica mais cara e precisa de mais treinamento;
Se utilizar tecnologias diferentes é preciso que todo time esteja treinado e engajado no projeto como um todo.

Conclusão.

Utilizar Microsserviços somente por ser uma novidade não é uma boa ideia, utilizar Microsserviços envolvem uma série de questões que devem ser analisados. Com essa análise as vezes pode ser melhor construir uma aplicação distribuída ou monolítica.

Arquitetura Hexagonal.

Já ouviu falar ou leu algo sobre Arquitetura Hexagonal?

Essa arquitetura mostra como podemos estruturar nosso projeto de forma organizada, protegida e escalável de uma forma simples.

Utilizando conceitos como Adapter/Port, Mediation e Application Domain essa arquitetura facilita muito trocas de variantes externas.

É importante lembrar que o DDD ou Domain Driven Design deve estar aplicado nessa arquitetura para que seja bem utilizado.

As vantagens em utilizar a Arquitetura Hexagonal são:

Proteção da camada de domínio da aplicação;
Separação de responsabilidade;
Facilidade de troca de componentes e fornecedores externos.

Acesse o material completo em: https://nakatech.herokuapp.com/article/arquiteturaHexagonal.html.