O Mito do Exactly-Once Delivery
A promessa de "exactly-once delivery" (entrega exatamente uma vez) é o Santo Graal dos sistemas distribuídos. Ferramentas de mensageria frequentemente alegam suportar esse comportamento, mas na prática, quando consideramos as leis da física da rede e possíveis falhas de hardware, exactly-once é uma ilusão matemática no nível da infraestrutura.
Por que Exactly-Once falha na prática?
Em sistemas distribuídos, existem duas garantias fáceis de atingir:
- At-most-once (No máximo uma vez): A mensagem é enviada e, se a rede falhar, ela é perdida.
- At-least-once (Pelo menos uma vez): A mensagem é enviada com confirmação (ACK). Se a confirmação for perdida por um timeout de rede, o produtor reenvia a mensagem. Isso garante a entrega, mas pode gerar mensagens duplicadas.
Para atingir exactly-once, o sistema precisa saber perfeitamente se a outra ponta recebeu e processou a mensagem, mesmo quando a conexão morre no exato milissegundo do ACK. Isso requer uma coordenação infinita que contraria o Teorema CAP.
A Solução: At-Least-Once + Idempotência
A única maneira segura de garantir o comportamento exatamente uma vez em fluxos de negócios críticos (como processamento de pagamentos ou estornos) é não exigir exactly-once da infraestrutura de rede, mas sim implementar a Idempotência na camada da aplicação.
[!TIP] Idempotência é a propriedade de uma operação que permite ser aplicada várias vezes sem alterar o resultado além da primeira aplicação.
Como o Sagaweaw resolve isso
O Sagaweaw foi desenhado assumindo que falhas e duplicações vão acontecer. Em vez de lutar contra a rede, ele foca em Idempotência e Retries previsíveis:
- Idempotency Keys: Cada Saga e Step recebe uma chave de idempotência (
IdempotencyKey). Se um step é re-executado por timeout, o Sagaweaw garante que a execução não gerará efeitos colaterais duplicados caso o sistema alvo suporte validação de chave. - Transações de Banco de Dados: A persistência da Sagaweaw em PostgreSQL garante que a mudança de estado da sua Saga seja atômica. O framework checa a base de dados antes de reexecutar qualquer lógica de negócios do Step, absorvendo a duplicação na camada do orquestrador.
Exemplo: Compensação de Saldo
Se a sua Saga falha após faturar o cliente (um step PIVOT) e você precisa fazer o rollback (estorno), não importa se a mensagem de rollback cair na rede ou for enviada três vezes por um RetryPolicy.exponential(). O seu step unblockBalance usará a chave da Saga para garantir que o cliente só seja estornado uma única vez, independentemente de cantos obscuros da rede.
Ao abraçar o caos e fornecer as ferramentas para idempotência estruturada, o Sagaweaw remove o peso de garantir infraestruturas perfeitas, delegando a consistência para o modelo transacional.
Junte-se ao debate!
Arquitetura é feita de trade-offs. O que você achou das decisões tomadas em "O Mito do Exactly-Once Delivery"? Compartilhe seus cenários, tire dúvidas e debata com outros engenheiros da comunidade Sagaweaw.
Comentar no GitHub Discussions