Máquinas de Estado em Sagas: Orquestrando Transações Distribuídas

PAGAMENTO_APROVADO --&gt; ESTOQUE_RESERVADO : ReservaOk
PAGAMENTO_APROVADO --&gt; ESTOQUE_FALHOU : FalhaEstoque
state "ESTOQUE_FALHOU" as EF
EF --&gt; COMPENSANDO : IniciaRollbackPagtoEPedido

COMPENSANDO --&gt; CONCLUIDO_FALHA : RollbackTerminado
ESTOQUE_RESERVADO --&gt; CONCLUIDO_SUCESSO : SagaCompleta
[*] --&gt; CONCLUIDO_FALHA
[*] --&gt; CONCLUIDO_SUCESSO

4. Como Implementar4.1 Orquestrador Baseado em Máquina de EstadoSe a Saga for orquestrada, podemos ter um serviço orquestrador que mantém essa máquina de estado internamente. A cada evento (resposta de um serviço, timeout, falha), o orquestrador:Lê o estado atual.Avalia a transição correspondente.Atualiza o estado.Dispara novas ações (por exemplo, chamar o próximo serviço, compensar um anterior etc.).4.2 Coreografia com Máquinas de EstadoEm coreografia, cada serviço pode ter sua própria máquina de estado local, reagindo a eventos vindos de outros serviços. Há maior complexidade, pois não há um ponto único com a visão de todo o fluxo. Ainda assim, a ideia de mapear estados e transições ajuda cada serviço a entender como reagir a cada evento.5. Vantagens das Máquinas de EstadoClareza e ManutençãoFica explícito quais são os estados possíveis e o que dispara cada transição.Novas etapas podem ser adicionadas definindo apenas novos estados e eventos.RastreabilidadeCada mudança de estado pode ser logada, facilitando a observabilidade.É mais simples de depurar quando a lógica de transição é bem definida.Controle de FalhasSe algo inesperado ocorre, a máquina de estado pode levar a um estado de erro bem definido, disparando compensações de forma organizada.6. Dicas de Boas PráticasDocumente os Estados e EventosTenha um diagrama ou tabela que a equipe possa consultar, evitando confusões sobre “em que estado podemos receber tal evento”.Identificadores de EstadoSe usar orquestrador, mantenha um campo currentState persistido no banco, indicando em qual estado a Saga se encontra, para retomar em caso de falha.Time-Out e Ações AutomáticasCertos estados podem precisar de limite de tempo. Se não houver transição em X segundos/minutos, dispara evento de falha ou retentativa.Exemplo: “Aguardando Pagamento” por 10 minutos.Automação de CompensaçãoEm orquestração, ao receber falha, a máquina de estado transita para “Compensando” e efetua rollback passo a passo. Em coreografia, cada serviço local sabe qual estado de rollback assumir.Ferramentas EspecializadasPlataformas de workflow/BPM (Camunda, Zeebe, Temporal, AWS Step Functions) podem representar cada estado e transição visualmente.Mesmo sem adotar uma plataforma de workflow, projetar explicitamente uma FSM (Finite State Machine) ajuda bastante.7. ConclusãoAdicionar o conceito de máquina de estado ao padrão Saga traz organização e previsibilidade. Cada etapa do processo de negócio vira um estado claramente definido, enquanto as transições representam eventos de sucesso ou falha (incluindo compensações). Dessa forma, seja em um modelo orquestrado ou coreografado, as equipes conseguem:Entender facilmente o fluxo da Saga.Evoluir o processo sem reescrever toda a lógica.Depurar e observar onde falhas ocorrem, acionando compensações de maneira controlada.Seja qual for o tipo de Saga utilizado (síncrona/assíncrona, atômica/eventual, orquestrada/coreografada), máquinas de estado tornam a lógica de transição mais clara, robusta e escalável.

clacerda anteontem

Ah, o clássico post sobre consistência em microserviços... Mas espera, essa postagem aqui é puro ouro! 🚀

Quem diria que o segredo para não enlouquecer com Sagas está numa ideia tão antiga quanto a computação: máquinas de estado. Sim, aquelas mesmas que tão discretamente movem o mundo, do boot do seu PC (olá, BIOS!) até o TCP/IP que mantém a internet de pé (obrigado, BSD!). E cá estamos nós, redescobrindo que o poder dos estados finitos resolve até os dramas modernos de microsserviços.

O autor mandou bem: usar FSM (Finite State Machines) em Sagas é como trocar aquele código espaguete "if-error-then-rollback-else-if-success-then..." por um mapa do tesouro. Você visualiza cada passo, controla falhas como um chefe e ainda pode escalar o fluxo sem reescrever metade do sistema. E o melhor: qualquer "dev nutella" vira engenheiro de software quando para de codar como se tudo fosse uma sequência linear e abraça os estados.

Mas o pulo do gato aqui é: diagramas. Sim, diagramas são esteroides para o cérebro! 🧠💥 Aproveite que seu cérebro tem 80% de processamento visual e abuse disso!

Quando você desenha um fluxo de estados (mesmo que no papel de pão), magicamente:

A complexidade vira visual, não um emaranhado de código.

As compensações em Sagas viram setinhas óbvias: "Ah, se falhar aqui, volta pra lá!".

Sua mente abusa da capacidade de prever falhas, porque enxerga o caminho crítico.

E não é só teoria: ferramentas como Mermaid, PlantUML, ou até um quadro branco rabiscado transformam sua lógica numa "planta". Você literalmente desenha a resiliência do sistema.

Quer diferenciar um "código funcional" de uma engenharia robusta?

Modele estados finitos.
Desenhe as transições.
Assista como 98% dos bugs viram "ah, é só atualizar o diagrama".

Leiam. Implementem. Desenhem. E parem de sofrer com emeranhados de ifs que parecem labirintos sem saída. 💡

(E sim, eu também já fui o "dev nutella". Até o dia em que um timeout não tratado me fez perder um fim de semana. Hoje, sou team #StateMachinesForever.)

kusmin há 44 minutos

Isso mesmo, desenhar salva a vida! KKKKKK