Se existe algo que incomoda engenheiros experientes é quando o sistema segue o fluxo, os testes passam, a arquitetura parece correta, e mesmo assim a confiança não vem.
Já vi esse cenário em sistemas de pagamento, orquestrações de pedidos e integrações críticas. O padrão está certo. O código está organizado. O pipeline está verde. Ainda assim, algo não fecha.
Foi exatamente desse incômodo que nasceu esta POC de SAGA em .NET.
Ela não existe para provar que o padrão funciona.
Ela existe para expor onde os contratos deixam de ser explícitos em sistemas distribuídos.
Demonstração antes da teoria: o fluxo “correto”
Na POC, o fluxo é simples e familiar:
- Um pedido é iniciado
- Serviços independentes executam suas responsabilidades
- Em caso de falha, ações de compensação são disparadas
Tudo isso segue o que se espera de uma SAGA clássica.
Nenhuma exceção estranha. Nenhum erro óbvio. Nenhum crash.
O sistema funciona.
E esse é justamente o problema.
Onde times maduros se enganam
Quando apresento esse tipo de fluxo para times experientes, a leitura costuma ser:
“Está certo. Se algo falhar, a compensação resolve.”
O erro não está na implementação do padrão.
Está na confiança implícita de que a compensação encerra o problema.
Em sistemas distribuídos reais:
- estados intermediários ficam vivos por mais tempo do que o esperado
- mensagens podem ser reprocessadas
- serviços interpretam sucesso de formas diferentes
O contrato entre serviços não é o código.
É o conjunto de suposições que ninguém formalizou.
SAGA não falha ruidosamente — ela degrada em silêncio
Ao contrário de APIs síncronas, onde contratos quebrados explodem rápido,
SAGAs tendem a falhar de forma progressiva.
Um serviço compensa.
Outro assume que o estado foi limpo.
Um terceiro age sobre dados que “não deveriam mais existir”.
Nenhum teste unitário captura isso.
Nenhum teste em staging reproduz o acúmulo.
É o mesmo tipo de risco que vemos hoje em sistemas de IA:
- comportamento esperado ≠ comportamento garantido
- confiança baseada em ambiente controlado
- variabilidade tratada como exceção
O peso dos sistemas distribuídos
A POC deixa algo evidente:
quanto mais serviços participam da SAGA, mais frágil se torna o contrato implícito entre eles.
Cada boundary adiciona:
- atraso
- interpretação própria de estado
- dependência de timing
É nesse ponto que padrões deixam de ser solução mágica e passam a ser amplificadores de erro, se não houver observabilidade e critérios claros.
Sistemas distribuídos não quebram porque o padrão é errado.
Eles quebram porque ninguém está validando continuamente se o contrato ainda é válido.
Um exemplo simples, mas perigoso
Imagine um fluxo de pedido:
- Serviço A cria o pedido
- Serviço B reserva estoque
- Serviço C processa pagamento
O pagamento falha. A compensação roda. O estoque é liberado.
Mas:
- o evento de liberação é reprocessado
- outro serviço reage a um estado transitório
- métricas continuam “boas”
Nenhuma exceção é lançada.
Nenhum alerta dispara.
O sistema já está inconsistente.
A SAGA “funcionou”.
O contrato, não.
Erros que vejo times maduros repetirem
- Confundir compensação com correção definitiva
- Assumir que staging representa produção
- Não versionar expectativas de estado
- Monitorar infraestrutura, mas não semântica
- Tratar SAGA como padrão de controle, não como risco a ser observado
Essa POC existe para provocar esse desconforto.
Não é um tutorial. É um artefato de diagnóstico.
O repositório não tenta ensinar SAGA passo a passo.
Ele materializa um problema recorrente: contratos invisíveis em sistemas distribuídos.
📌 Repositório da POC:
https://github.com/felipemarcianodev/saga-poc-dotnet
Se você leu esperando uma “implementação correta”, pode se frustrar.
Se leu pensando “isso já aconteceu comigo”, então o objetivo foi cumprido.
Sem checklist, sem receita pronta
Não existe framework que resolva contrato implícito.
Existe maturidade para:
- explicitar suposições
- observar comportamento real
- diagnosticar riscos antes do incidente
Essa é a motivação por trás do projeto Felipe Marciano:
usar código, arquitetura e POCs não como vitrine, mas como instrumentos de reflexão técnica.
Se sua SAGA funciona…
mas você não consegue explicar por que confia nela,
talvez o problema não esteja no padrão —
mas no contrato que nunca foi assumido conscientemente.
Diagnóstico técnico para projetos com IA e sistemas complexos
Se você está:
- enfrentando comportamentos imprevisíveis em integrações com IA,
- sentindo dificuldade em testar fluxos automatizados,
- ou percebe que o sistema “funciona”, mas não transmite confiança,
talvez o problema não esteja no modelo de IA, mas na forma como o cenário foi desenhado e validado.
No meu serviço de diagnóstico técnico, analiso:
- arquitetura do sistema,
- definição de cenários e regras de negócio,
- estratégia de testes (incluindo prompts e automações),
- pontos de variabilidade e risco invisíveis no dia a dia.
O objetivo não é vender uma solução pronta, mas clarear decisões técnicas, reduzir incertezas e apontar caminhos possíveis com base em engenharia, não em hype.
Se quiser entender se esse diagnóstico faz sentido para o seu contexto, entre em contato pelas minhas redes ou através do meu site https://felipemarcianodev.com/diagnostico.
Gostou do conteúdo? Se você também se interessa por arquitetura de software, testes, domínio e uso responsável de IA no dia a dia de desenvolvimento, vale continuar essa conversa por aqui:
- https://www.linkedin.com/in/felipe-santos-marciano/
- https://www.instagram.com/felipemarcianodev/
- YouTube
- https://www.youtube.com/@felipemarcianodev
- https://www.facebook.com/felipesantos.marciano/
- TikTok
- https://www.tiktok.com/@felipemarcianodev
Compartilho aprendizados reais de projetos, decisões técnicas e reflexões que normalmente não aparecem em posts “perfeitos” de tecnologia.
