Fairy Tale Saga: Síncrona, Consistência Eventual e Orquestrada

Entre as diferentes variações de Sagas em arquiteturas de microserviços, há um modelo conhecido como Fairy Tale Saga, no qual as chamadas são feitas de forma síncrona, a consistência se resolve de maneira eventual e a coordenação é centralizada via orquestração. Este artigo descreve como esse padrão funciona, suas características gerais e um exemplo de aplicação.


1. Definição e Características

  1. Comunicação Síncrona
    • O orquestrador chama cada serviço de forma bloqueante, aguardando resposta (sucesso/falha) antes de prosseguir.
  2. Consistência Eventual
    • Ainda que cada passo seja chamado de forma imediata, não se busca atomicidade estrita. As etapas podem ser confirmadas localmente e, em caso de falha em uma etapa posterior, as compensações são aplicadas para reverter estados anteriores.
    • Enquanto essas compensações não são totalmente efetivadas, o sistema pode apresentar estados “intermediários”.
  3. Orquestração Centralizada
    • Um orquestrador governa a ordem das chamadas e inicia as ações de compensação se necessário.
    • Todo o fluxo e as lógicas de rollback são controlados por esse componente.

A combinação desses três elementos permite que cada serviço execute operações e devolva uma resposta de forma síncrona, enquanto a consistência geral depende do mecanismo de “confirmação e compensação” típico de Sagas, gerando uma forma de consistência eventual.


2. Por que Consistência Eventual em Chamada Síncrona?

Mesmo com chamadas síncronas, cada serviço confirma sua etapa de forma independente. Se falhas ocorrerem em etapas futuras, o orquestrador dispara compensações, mas não há uma transação indivisível envolvendo todos os participantes simultaneamente. Isso significa que:

  • O estado de cada serviço pode temporariamente divergir enquanto não se executa a compensação.
  • O orquestrador coordena a volta ao estado coerente, mas isso não acontece instantaneamente no momento da falha — exigindo um período para a eventual aplicação dos rollbacks.

3. Funcionamento Geral

3.1 Sequência de Execução

  1. Início da Saga
    • O orquestrador recebe a solicitação para iniciar o processo.
  2. Chamada Síncrona ao Serviço 1
    • O orquestrador aguarda a resposta (sucesso/falha).
  3. Chamada Síncrona ao Serviço 2
    • Em caso de sucesso anterior, segue para a próxima etapa; em falha, aciona compensações no Serviço 1.
  4. Demais Etapas
    • Repete o padrão de chamar cada serviço até concluir o fluxo. Em qualquer falha, o orquestrador inicia rollbacks nas etapas já confirmadas.

3.2 Consistência Eventual

  • Se o Serviço 3 falhar, o Serviço 1 e o Serviço 2 podem já ter gravado mudanças que precisarão ser revertidas.
  • O orquestrador, ao perceber a falha, dispara as compensações necessárias. Enquanto não forem concluídas, o estado global ainda não refletirá a coerência final esperada.

4. Exemplo de Uso

Imagine um processo de cadastro e pedido em três etapas:

  1. Serviço de Clientes (criação do perfil do cliente)
  2. Serviço de Estoque (reserva do item)
  3. Serviço de Faturamento (processamento do pedido)

Fluxo:

  1. O orquestrador chama o Serviço de Clientes (Síncrono).
    • Em caso de sucesso, parte para o Estoque.
    • Em falha, aborta a Saga (se for a etapa inicial, não há compensações anteriores).
  2. Chama o Serviço de Estoque.
    • Se houver problema, aciona a compensação no Serviço de Clientes (por exemplo, descartar ou inativar o perfil criado) e finaliza.
    • Se sucesso, segue para Faturamento.
  3. Chama o Serviço de Faturamento.
    • Em caso de falha, inicia compensações nos serviços anteriores para reverter as mudanças.
    • Se tudo der certo, a Saga termina com sucesso.

Nesse cenário, a consistência é eventulamente obtida: caso o Faturamento falhe, ainda haverá um lapso de tempo antes de concluir a reversão no Estoque e no cadastro do Cliente.


5. Desenho em Diagrama

sequenceDiagram
    autonumber
    participant O as Orquestrador
    participant S1 as Serviço 1
    participant S2 as Serviço 2
    participant S3 as Serviço 3

    O->>S1: Chamada Síncrona (Etapa 1)
    S1-->>O: Sucesso ou Erro
    alt Sucesso
        O->>S2: Chamada Síncrona (Etapa 2)
        S2-->>O: Sucesso ou Erro
        alt Sucesso
            O->>S3: Chamada Síncrona (Etapa 3)
            S3-->>O: Sucesso ou Erro
            alt Falha
                O->>S2: Compensar Etapa 2
                O->>S1: Compensar Etapa 1
            else Sucesso
                O-->>O: Saga Concluída
            end
        else Falha
            O->>S1: Compensar Etapa 1
        end
    else Falha
        O-->>O: Saga Encerrada (sem compensações anteriores)
    end

Cada confirmação de sucesso atualiza o estado local do serviço correspondente; já uma falha leva o orquestrador a disparar reversões. Esses rollbacks podem levar algum tempo, implicando na eventual convergência para um estado consistente.


6. Observações Gerais

6.1 Tempo de Bloqueio Síncrono

Cada etapa depende do término da anterior antes de iniciar a próxima. Em ambientes com muitas requisições simultâneas, é necessário considerar a capacidade de lidar com possíveis atrasos sem gerar acúmulo de chamadas pendentes.

6.2 Logging e Observabilidade

Como o orquestrador gerencia todas as etapas, é recomendável manter logs que facilitem entender o estado atual da saga, incluindo as compensações em andamento, a fim de identificar rapidamente em que ponto ocorrem falhas ou atrasos.

6.3 Rollbacks em Etapas Anteriores

Os rollbacks seguem o mesmo padrão síncrono. Ao detectar falhas, o orquestrador inicia compensações sequencialmente. Nesse meio tempo, o sistema pode apresentar divergências entre o status do cliente, estoque e faturamento até que as correções sejam aplicadas.


7. Conclusão

No Fairy Tale Saga (Síncrona, Consistência Eventual, Orquestração), o foco está em:

  • Chamadas síncronas entre o orquestrador e os serviços,
  • Confirmações rápidas após cada passo, com posterior compensação em caso de falha,
  • Resolução de inconsistências de forma eventual, por meio de rollbacks orquestrados centralmente.

Cada cenário específico pode adotar essa abordagem conforme a lógica de negócio demandar, combinando maior controle centralizado com a possibilidade de retentativas e compensações em situações de erro.