Outbox Pattern(Saga): Transações distribuídas com microservices
Se você aplicou o padrão de banco de dados por serviço (Single Database per Service), cada serviço tem seu próprio banco, mas algumas transações comerciais abrangem vários serviços.
O que é o Padrão Saga?
O padrão Saga traz algumas formas de resolver o problema de transações distribuídas envolvendo microservices.
Uma saga é uma sequência de transações locais. Cada transação local atualiza o banco de dados e publica uma mensagem ou evento para acionar a próxima transação local na saga. Se uma transação local falhar porque viola uma regra de negócios, a saga executa uma série de transações compensatórias que desfazem as alterações feitas pelas transações locais anteriores.
Existem duas estratégias para se implementar o Saga: Orquestração e Coreografia.
Orquestração
Nesse modelo existe um componente central, também conhecido como Saga Execution Coordinator (SEC), que aciona todos os serviços envolvidos, dizendo quais operações eles devem realizar. Caso essa transação falhe, esse componente também orquestra as operações de rollback com os serviços envolvidos.
Coreografia
Nesse modelo cada transação local publica eventos de domínio que acionam transações locais em outros serviços. Nesse cenário cada serviço sabe qual evento disparar e qual evento ouvir para que a Saga seja completa. É de responsabilidade de cada serviço avisar ao seu sucessor que conseguiu realizar com sucesso ou ao seu antecessor que ocorreu uma falha.
Outbox Pattern
Vamos nos aprofundar na implementação Saga conhecida como Outbox.
Cenário: imagine que, ao receber um pedido, o serviço Order o grava em seu próprio banco de dados e no passo seguinte faz uma solicitação enviando uma mensagem ao serviço Payment para dar continuidade ao processo de compra, seguindo para aprovação do pagamento.
Problema: se ocorrer algum erro no processo de enviar essa mensagem, esse pedido já estará salvo no banco, mas o serviço Payment não receberá nenhuma mensagem para prosseguir com o processo.
O Outbox pattern permite publicar eventos de forma confiável. A ideia é que, quando sua API publica mensagens, ela não as envie diretamente. Em vez disso, as mensagens são persistidas em uma tabela do banco de dados (na mesma transação em que o pedido for gravado) e depois disso, um worker consome esses registros e publica essas mensagens no broker, em intervalos de tempo predefinidos.
Com isso temos a garantia de que todo o processo será executado completamente, tanto em caso de sucesso quanto em caso de falha.
