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.
Join the discussion!
Architecture is about trade-offs. What do you think about the decisions made in "Lidando com Rollbacks Parciais"? Share your scenarios, ask questions, and debate with other engineers in the Sagaweaw community.
Comment on GitHub Discussions