Fantasy Fiction Saga: Atômico, Assíncrono e Orquestrado

No mapeamento das diferentes combinações de Sagas em microserviços, o Fantasy Fiction Saga descreve um modelo em que a comunicação é assíncrona, a busca de consistência se assemelha ao formato atômico (ou “tudo ou nada”) e existe um orquestrador central para coordenar os passos. Neste artigo, veremos como essa abordagem funciona, seus principais desafios e um exemplo de fluxo típico.

1. Características Fundamentais

1. Comunicação Assíncrona
   • As interações entre o orquestrador e os serviços (ou entre os próprios serviços) ocorrem via mensageria, filas ou eventos, não de forma bloqueante.
2. Atômico (“tudo ou nada”)
   • Busca-se aproximar a transação distribuída de uma atomicidade estrita, na qual todas as etapas são confirmadas juntas ou revertidas integralmente.
   • Embora cada etapa seja realizada localmente, o orquestrador gerencia confirmações e, se houver falha, inicia compensações de maneira centralizada.
3. Orquestração
   • Um componente (orquestrador) controla a ordem de execução, recebendo mensagens de sucesso ou falha, e definindo o momento de acionar compensações.
   • Todos os serviços reportam ao orquestrador o status das operações.

O termo “Fantasy Fiction” aqui sugere a ideia de um “mundo” no qual muitas coisas precisam dar certo simultaneamente, e qualquer falha desencadeia um reverter completo, tudo coordenado por um “mestre” do fluxo.

2. Como Funciona o Fluxo

2.1 Orquestrador Dispara Mensagens

• O orquestrador envia mensagens para cada etapa (Serviço A, B, C etc.) por meio de um broker (fila, tópico de mensagens) ou notificação assíncrona.
• Cada serviço, ao receber a mensagem, processa a solicitação de forma local e envia uma resposta (ex.: mensagem de sucesso ou falha) ao orquestrador.

2.2 Objetivo de Atomicidade

• Diferentemente de uma Saga tradicional de “confirma e compensa” com consistência eventual, a proposta do Fantasy Fiction Saga é sincronizar as confirmações de modo que todas ocorram ou todas sejam revertidas.
• É comum o orquestrador aguardar mensagens de “pronto para confirmar” de cada serviço. Somente após receber todas as confirmações parciais, ele envia uma mensagem final de “commit” (ou “rollback”, se ocorrer falha).

2.3 Compensações Centralizadas

• Se algum serviço sinalizar erro, o orquestrador notifica os demais (ou os que já sinalizaram “pronto para confirmar”) para revertê-los.
• Isso ainda se baseia em um padrão de compensação, mas com o menor espaço possível entre a fase de “preparação” e a de “commit” efetivo, numa tentativa de reproduzir uma atomicidade.

3. Desafios

3.1 Garantia de Mensagens

Em comunicação assíncrona, garantir que cada serviço receba e envie confirmações de maneira confiável pode envolver:

• Mensageria Resiliente: Filas e tópicos com alta disponibilidade, estratégias de retentativa e DLQ (Dead Letter Queue) em caso de falhas na entrega.
• Controle de Duplicidade: Um mesmo serviço pode receber mensagens em duplicidade e deve tratar isso de forma idempotente.

3.2 Complexidade Similar a um 2PC

Essa busca por atomicidade via orquestração e comunicação assíncrona pode remeter a um comportamento semelhante ao “Two-Phase Commit” (2PC). É preciso lidar com:

• Uma primeira fase de “prepare” (ou check) em que cada serviço confirma que pode aplicar a operação.
• Uma segunda fase de “commit” (ou “abort”), decidida pelo orquestrador conforme o resultado global.

3.3 Latência e Estados Temporários

Enquanto o orquestrador aguarda a confirmação de todos, alguns serviços podem ter aplicado suas operações localmente (em modo “tentativo”). Caso ocorra falha em outro serviço, há um rollback. Isso requer que cada serviço mantenha logs de transação ou outro mecanismo que permita voltar atrás caso o commit não seja autorizado.

4. Exemplo Simplificado

Suponha um processo de venda que inclua três serviços:

1. Serviço de Pedido (A)
2. Serviço de Pagamento (B)
3. Serviço de Entrega (C)

Fluxo (Fases):

1. Orquestrador envia mensagem “inicie pedido” a A, B, C (cada um em paralelo ou em sequência, conforme a lógica).
2. Serviços respondem com “pronto para confirmar” ou falha.
   • Se todos indicam “pronto para confirmar”, o orquestrador envia a mensagem de “commit” a todos, finalizando a transação.
   • Se algum serviço falhar, o orquestrador envia “rollback” às demais partes que já estavam prontas, solicitando compensações (cancelamento de pedido, estorno de pagamento etc.).
3. Os serviços que recebem “rollback” efetuam a compensação local e noticiam o orquestrador. Depois disso, a saga é dada como encerrada.

Durante esse período, cada serviço mantém um estado temporário (ex.: reserva de estoque ou cartão pré-autorizado) que só se torna definitivo quando chega a mensagem de commit. Em caso de falha, essas reservas ou autorizações são revogadas.

5. Observações sobre Atomicidade

• Embora a proposta seja “atômica”, ainda estamos em um contexto de “confirma e compensa”. O orquestrador tenta manter um intervalo de tempo mínimo entre o “prepare” e o “commit”, mas cada serviço executa as etapas localmente.
• Se ocorrerem falhas na comunicação com algum serviço durante a fase final, o orquestrador poderá precisar de novas retentativas ou poderá abortar toda a transação para garantir a consistência, disparando compensações nos serviços que já haviam recebido o commit.

6. Vantagens e Considerações

6.1 Vantagens

• Menos Bloqueio Síncrono: Como a comunicação é assíncrona, os serviços não ficam bloqueados esperando a resposta imediata; podem processar em segundo plano.
• Coordenação Centralizada: Facilita a visualização do fluxo, pois o orquestrador sabe o status de cada participante.
• Aparência de Atomicidade: Buscando sincronizar as confirmações, a transação final parece “tudo ou nada” ao usuário.

6.2 Considerações Importantes

• Complexidade Semelhante a 2PC: A implementação requer protocolos bem estabelecidos para lidar com falhas e retentativas, evitando estados presos ou inconsistências.
• Estado Temporário em Cada Serviço: Os participantes precisam de uma forma de registrar seus dados provisórios até que chegue o commit final.
• Observabilidade: Um sistema de logs, correlação de mensagens e tracing é fundamental para monitorar e depurar o fluxo, dado o caráter assíncrono.

7. Conclusão

O Fantasy Fiction Saga (Atômico, Assíncrono, Orquestrado) descreve um padrão em que:

• A comunicação ocorre via mensagens não bloqueantes,
• O orquestrador coordena as fases de preparo e confirmação,
• Busca-se uma transação quase atômica, onde todos confirmam juntos ou todos retornam atrás.

Essa abordagem se aproxima de um Two-Phase Commit distribuído usando Sagas, com ênfase em um orquestrador que coleta respostas de cada serviço antes de autorizar o commit final. A robustez da mensageria, a definição clara de fases e a idempotência dos participantes são aspectos centrais para viabilizar esse modelo, que permite fornecer uma experiência de “tudo ou nada” em cenários distribuídos — ainda que, internamente, a mecânica seja de “confirma e compensa”.