Lidando com Rollbacks Parciais
Um dos maiores desafios na orquestração de microsserviços não é o caminho feliz, nem mesmo o caminho triste onde tudo falha. O verdadeiro pesadelo arquitetural ocorre nos Rollbacks Parciais.
Imagine o cenário:
- Você processa um pagamento (Sucesso)
- Você reserva o estoque (Sucesso)
- Você emite a nota fiscal (Falha irrecuperável)
O Sagaweaw iniciará o fluxo de compensação. Primeiro, ele cancela a reserva de estoque. Mas e se o cancelamento do pagamento (estorno) no provedor externo falhar por timeout de rede?
A Armadilha do Estado Intermediário
Sistemas de coreografia baseados em eventos puros (como Kafka/RabbitMQ soltos) geralmente deixam esse sistema em um estado intermediário inconsistente (dinheiro cobrado, pedido não entregue). Para arrumar isso, você precisaria criar cronjobs de conciliação diários que vasculham o banco de dados.
Como o Sagaweaw lida com isso
Com a orquestração do Sagaweaw, os steps compensatórios que falham entram em estado RETRIABLE COMPENSATING. O orquestrador central nunca "esquece" que aquele dinheiro precisa ser devolvido.
Ele continuará tentando acionar o método .compensate() de acordo com a política de retry (ex: backoff exponencial infinito) até que a API do gateway de pagamento retorne um HTTP 200 OK, momento em que a Saga transiciona para COMPENSATED.
Isso só é possível porque armazenamos o estado de cada transição de step de forma atômica no banco relacional, garantindo durabilidade máxima mesmo se a aplicação inteira for reiniciada durante o rollback.
Junte-se ao debate!
Arquitetura é feita de trade-offs. O que você achou das decisões tomadas em "Lidando com Rollbacks Parciais"? Compartilhe seus cenários, tire dúvidas e debata com outros engenheiros da comunidade Sagaweaw.
Comentar no GitHub Discussions