This content originally appeared on DEV Community and was authored by Filipi Firmino
Bora falar de Sagas?
Garantir consistência de dados em sistemas distribuídos é, sem exagero, um dos maiores perrengues que a gente enfrenta quando entra no mundo dos microsserviços. É tipo tentar manter várias bandas tocando juntas sem maestro — cada uma no seu ritmo, mas tudo tem que soar em harmonia.
E é aí que entra o Saga Pattern: um jeito moderno e bem pragmático de coordenar serviços diferentes, sem perder escalabilidade nem resiliência.
🤔 Por que a gente precisa de Sagas?
Num monolito, a vida é mais simples: tudo roda num banco central, transações ACID cuidam da consistência e tá tudo certo.
Mas em microsserviços... cada domínio tem seu próprio banco. Então, imagina fechar um pedido de e-commerce — você precisa mexer em pedido, pagamento, estoque e entrega, tudo ao mesmo tempo e de forma sincronizada.
Se uma dessas etapas falha, tipo o pagamento passa, mas o estoque não tá disponível... pronto, o sistema fica num estado meio zumbi.
O Saga Pattern resolve exatamente isso: ele evita esses cenários "meio do caminho", garantindo que, se algo der errado, o sistema saiba como se recuperar — compensando as ações e voltando pra um estado consistente.
⚙️ Como o Saga Pattern funciona na prática
A ideia é dividir uma grande transação em várias transações locais.
Cada microserviço faz sua parte (de forma ACID local) e, se alguma etapa der ruim, o sistema executa transações compensatórias pra desfazer o que já foi feito.
Assim, mesmo com falhas ou timeouts, o sistema não quebra — ele se ajusta e segue a vida.
Em resumo:
- Cada serviço cuida da sua transação local;
- A comunicação entre eles acontece por eventos ou comandos;
- Se algo falha, rola compensação e nada fica “órfão” no sistema.
Tipos de Sagas: Coreografia vs Orquestração
Coreografada:
Cada serviço reage a eventos e publica seus próprios — tipo uma dança sincronizada sem maestro.
É leve e funciona bem pra fluxos simples, mas conforme o sistema cresce, vira um caos entender quem chama quem.
Orquestrada:
Aqui entra um “maestro”: o orquestrador.
Ele coordena o fluxo, chama os serviços (síncrono ou assíncrono), espera respostas e dispara compensações quando algo falha.
Esse modelo é ótimo pra cenários mais críticos — tipo financeiro, pagamentos ou e-commerce de grande porte — porque dá rastreabilidade e facilita observabilidade.
🔄 Ciclo de Vida e Estado
Uma boa implementação de saga geralmente usa máquinas de estado pra acompanhar tudo:
Iniciado → Reservando estoque → Pagando → Entregando → Finalizado.
Isso garante:
- Idempotência (se rodar duas vezes, o resultado é o mesmo),
- Resiliência (suporte a retries, timeouts, intervenção manual),
- Auditoria (você sabe exatamente onde algo deu ruim).
🔁 Compensações: o segredo da consistência
Pensa assim: se o pagamento falha, o sistema automaticamente desfaz o que já fez — tipo cancelar o pedido, liberar o estoque e reembolsar o valor.
Essas ações compensatórias são o coração do Saga Pattern e o que garante que o sistema continue íntegro, sem dados zumbis vagando pelo banco.
⚠️ Desafios e Boas Práticas
Alguns pontos pra ficar de olho:
Dual Write: gravar no banco e publicar evento ao mesmo tempo pode dar ruim se rolar falha no meio. Padrões como Outbox ou Change Data Capture ajudam muito aqui.
- Observabilidade: log detalhado, métricas e tracing distribuído são obrigatórios.
- Idempotência: sempre projete handlers que suportem reexecuções sem causar bagunça.
- Compensações bem definidas: se tem CobrarPedido(), precisa ter EstornarCobranca().
Se você tá no ecossistema .NET, existem várias opções pra implementar sagas:
- MassTransit (integra bem com RabbitMQ, Azure Service Bus, etc.);
- NServiceBus;
- Ou até usando Dapr e Azure Durable Functions, se quiser algo mais workflow-oriented.
A escolha entre coreografia e orquestração vai depender do cenário — se o foco é rastreabilidade e controle, orquestração costuma ganhar.
💡 Exemplo prático (pseudocódigo com MassTransit)
public class PedidoSaga : MassTransitStateMachine<PedidoState>
{
public PedidoSaga()
{
InstanceState(x => x.Status);
Initially(
When(PedidoCriado)
.Then(context => context.Instance.PedidoId = context.Data.PedidoId)
.Publish(context => new ReservarEstoque { PedidoId = context.Instance.PedidoId })
.TransitionTo(Reservando)
);
During(Reservando,
When(EstoqueReservado)
.Publish(context => new ProcessarPagamento { PedidoId = context.Instance.PedidoId })
.TransitionTo(Pagando),
When(ReservaFalhou)
.Publish(context => new CancelarPedido { PedidoId = context.Instance.PedidoId })
.Finalize()
);
SetCompletedWhenFinalized();
}
}
No modelo coreografado, cada serviço publicaria eventos e escutaria eventos de outros, agindo de forma independente:
PedidoCriado → Evento:PedidoCriado → Serviço Estoque responde
(EstoqueReservado) / (FalhaReservaEstoque)
Quando (e por que) usar ou evitar uma Saga?
- Use saga quando houver múltiplos serviços e a consistência dos dados entre eles for obrigatória para o negócio;
- Evite em cenários de baixa criticidade ou quando a implementação e manutenção do padrão trouxerem mais complexidade que benefícios.
Conclusão
O Saga Pattern não é bala de prata, mas está entre os padrões mais robustos e pragmáticos para lidar com consistência de dados distribuídos em microsserviços, especialmente em cenários críticos como e-commerce e financeiro. Aplicado de forma consciente, transforma sistemas frágeis em soluções resilientes, auditáveis e evolutivas.
This content originally appeared on DEV Community and was authored by Filipi Firmino
Filipi Firmino | Sciencx (2025-11-01T14:48:41+00:00) Saga Pattern: Consistência de Dados em Microsserviços de Verdade. Retrieved from https://www.scien.cx/2025/11/01/saga-pattern-consistencia-de-dados-em-microsservicos-de-verdade/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.