Executando verificação de segurança...
4
kusmin
7 min de leitura ·

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

Quando implementamos Sagas em microserviços, uma forma de organizar a lógica de cada passo (e de suas compensações) é por meio de máquinas de estado (state machines). Nesse modelo, cada etapa do fluxo pode ser vista como um estado, com transições que levam a novos estados de sucesso ou falha. Desta forma, ganha-se clareza no desenho do processo e na forma como compensações são disparadas em caso de erro.

1. Por Que Usar Máquinas de Estado em Sagas?

  1. Visualização e Organização
    • A Saga pode ser modelada como um “fluxo” de estados: “Iniciando”, “Em Execução”, “Compensando”, “Concluído” etc.
    • É mais fácil de explicar e manter, pois a equipe enxerga claramente cada transição.
  2. Controle de Erros e Exceções
    • Se um serviço falha no meio do caminho, a máquina de estado passa a um estado de erro, iniciando compensações de forma previsível.
    • Cada estado tem suas próprias transições para encaminhar falhas ou retentativas.
  3. Fácil Evolução
    • Precisa inserir um passo extra ou um novo fluxo de compensação? Basta criar novos estados e transições, sem refatorar toda a lógica procedural.

2. Conceitos Básicos de Máquina de Estado

Uma máquina de estado (Finite State Machine – FSM) é definida por:

  1. Conjunto de Estados: Possíveis situações em que o fluxo pode se encontrar (por exemplo, “Aguardando Pagamento”, “Pagamento Aprovado”, “Pagamento Falhou”).
  2. Eventos ou Ações: O que causa a transição entre estados (receber resposta de outro serviço, um timeout, um evento de falha, etc.).
  3. Transições: A mudança de um estado para outro, disparada por determinado evento ou condição.
  4. Estado Inicial e Estado Final: Onde o fluxo começa e onde termina (com sucesso ou falha).

No padrão Saga, cada “passo” (transação local em um microserviço) pode corresponder a um estado, e a “compensação” é um evento/transição que leva a outros estados de correção ou rollback.

3. Exemplo de Máquina de Estado para uma Saga

Suponha um processo de criação de pedido em 3 passos:

  1. Criar Pedido (Serviço de Pedidos)
  2. Processar Pagamento (Serviço de Pagamento)
  3. Reservar Estoque (Serviço de Inventário)

3.1 Definindo Estados

  • PEDIDO_INICIADO: Saga acabou de começar, pedido ainda não criado.
  • PEDIDO_CRIADO: Pedido criado com sucesso, aguardando pagamento.
  • PAGAMENTO_APROVADO: Pagamento ok, próximo passo é reservar estoque.
  • PAGAMENTO_FALHOU: Pagamento falhou, iniciar compensação do pedido.
  • ESTOQUE_RESERVADO: Estoque reservado, a saga está próxima do fim.
  • ESTOQUE_FALHOU: Falhou na reserva, compensar pagamento e pedido.
  • COMPENSANDO: Estado genérico de rollback em andamento.
  • CONCLUIDO_SUCESSO: Estado final de sucesso.
  • CONCLUIDO_FALHA: Estado final de falha após compensações.

3.2 Transições

  • (Evento: Pedido Criado):
    • PEDIDO_INICIADO → PEDIDO_CRIADO
  • (Evento: Pagamento OK):
    • PEDIDO_CRIADO → PAGAMENTO_APROVADO
  • (Evento: Pagamento Falhou):
    • PEDIDO_CRIADO → PAGAMENTO_FALHOU
    • Em seguida, transição para COMPENSANDO (para desfazer o pedido).
  • (Evento: Estoque OK):
    • PAGAMENTO_APROVADO → ESTOQUE_RESERVADO
  • (Evento: Estoque Falhou):
    • PAGAMENTO_APROVADO → ESTOQUE_FALHOU
    • Em seguida, transição para COMPENSANDO (para reverter pagamento e pedido).
  • (Evento: Compensação Concluída com Falha):
    • COMPENSANDO → CONCLUIDO_FALHA
  • (Evento: Tudo OK):
    • ESTOQUE_RESERVADO → CONCLUIDO_SUCESSO

3.3 Ilustração em Diagrama

stateDiagram-v2
    [*] --> PEDIDO_INICIADO
    PEDIDO_INICIADO --> PEDIDO_CRIADO : PedidoCriado
    PEDIDO_CRIADO --> PAGAMENTO_APROVADO : PagamentoOk
    PEDIDO_CRIADO --> PAGAMENTO_FALHOU : PagamentoErro
    state "PAGAMENTO_FALHOU" as PF
    PF --> COMPENSANDO : IniciaRollbackPedido

PAGAMENTO_APROVADO --> ESTOQUE_RESERVADO : ReservaOk
PAGAMENTO_APROVADO --> ESTOQUE_FALHOU : FalhaEstoque
state "ESTOQUE_FALHOU" as EF
EF --> COMPENSANDO : IniciaRollbackPagtoEPedido

COMPENSANDO --> CONCLUIDO_FALHA : RollbackTerminado
ESTOQUE_RESERVADO --> CONCLUIDO_SUCESSO : SagaCompleta
[*] --> CONCLUIDO_FALHA
[*] --> CONCLUIDO_SUCESSO

4. Como Implementar

4.1 Orquestrador Baseado em Máquina de Estado

Se 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:

  1. Lê o estado atual.
  2. Avalia a transição correspondente.
  3. Atualiza o estado.
  4. Dispara novas ações (por exemplo, chamar o próximo serviço, compensar um anterior etc.).

4.2 Coreografia com Máquinas de Estado

Em 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 Estado

  1. Clareza e Manutenção
    • Fica 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.
  2. Rastreabilidade
    • Cada mudança de estado pode ser logada, facilitando a observabilidade.
    • É mais simples de depurar quando a lógica de transição é bem definida.
  3. Controle de Falhas
    • Se 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áticas

  1. Documente os Estados e Eventos
    • Tenha um diagrama ou tabela que a equipe possa consultar, evitando confusões sobre “em que estado podemos receber tal evento”.
  2. Identificadores de Estado
    • Se usar orquestrador, mantenha um campo currentState persistido no banco, indicando em qual estado a Saga se encontra, para retomar em caso de falha.
  3. Time-Out e Ações Automáticas
    • Certos 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.
  4. Automação de Compensação
    • Em 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.
  5. Ferramentas Especializadas
    • Plataformas 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ão

Adicionar 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.

Fonte: https://bytes.updev.dev.br/maquinas-de-estado-em-sagas-orquestrando-transacoes-distribuidas/

Carregando publicação patrocinada...
1
clacerda

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?

  1. Modele estados finitos.

  2. Desenhe as transições.

  3. 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.)