Parallel Saga: Assíncrono, Consistência Eventual e Orquestrado

No universo das Sagas em microserviços, o Parallel Saga combina comunicação assíncrona, consistência eventual e coordenação centralizada (orquestração), permitindo que múltiplas etapas sejam disparadas em paralelo sem bloquear o restante do fluxo. Este artigo descreve como esse padrão funciona, os principais elementos de implementação e os desafios que surgem ao orquestrar tarefas concorrentes em um modelo de “confirma e compensa”.

1. Definição e Características

1. Comunicação Assíncrona
   • Cada serviço troca mensagens ou eventos via filas, tópicos ou brokers, sem bloqueio de requisição/resposta.
2. Consistência Eventual
   • Os dados podem ficar temporariamente desalinhados. Se alguma tarefa falhar, o orquestrador inicia compensações nos serviços que já concluíram suas partes.
3. Orquestração
   • Um componente central (orquestrador) coordena o disparo das atividades, cuidando de agrupar as respostas de cada serviço e decidir se tudo pode prosseguir ou se é necessário acionar rollbacks.

1.1 Execução em Paralelo

O conceito de “parallel” sugere que o orquestrador pode enviar mensagens para diversos serviços ao mesmo tempo, em vez de aguardar a resposta de um serviço para só então chamar o próximo. Dessa forma, a latência global tende a cair, pois várias tarefas podem rodar simultaneamente.

2. Como Funciona na Prática

2.1 Disparo Simultâneo

• O orquestrador envia mensagens a múltiplos serviços (S1, S2, S3, etc.) via um broker de mensageria. Cada serviço processa sua parte e devolve uma resposta assíncrona (ex.: “Sucesso” ou “Falha”).

2.2 Agrupamento de Resultados

• O orquestrador mantém um estado que registra quais serviços responderam e em que status (por exemplo, S1 = “Sucesso”, S2 = “Falha”, S3 = “Em andamento” etc.).

2.3 Consistência Eventual

• Se algum serviço reportar falha, o orquestrador envia comandos de compensação para os demais, revertendo o que foi feito.
• Enquanto esses rollbacks não forem concluídos, o sistema fica num estado intermediário, de “inconsistência temporária”. Quando a compensação acaba, o sistema retorna a um estado coerente.

2.4 Continuação do Fluxo

• Se todos os serviços da fase paralela retornarem “Sucesso”, o orquestrador pode partir para a próxima fase (que pode também rodar em paralelo). Assim, a saga avança em “blocos” de atividades que podem ser simultâneas.

3. Exemplo Ilustrativo

Imagine um fluxo de e-commerce que, em determinado ponto, precise:

1. Notificar o Serviço de Pagamentos para confirmar valores.
2. Informar o Serviço de Estoque para separar os itens.
3. Solicitar ao Serviço de Pontos a adição de recompensas para o cliente.

No Parallel Saga:

1. O orquestrador publica mensagens para Pagamentos, Estoque e Pontos simultaneamente.
2. Cada serviço processa de forma assíncrona e devolve “OK” ou “Erro” ao orquestrador.
3. Se todos retornarem “OK”, a saga prossegue para o próximo estágio. Se qualquer um falhar, o orquestrador envia mensagens de rollback aos que responderam “OK”, removendo itens reservados ou estornando pagamentos, até restabelecer a consistência.

4. Desafios e Boas Práticas

4.1 Controle de Conclusão

• É necessário um mecanismo de contagem ou de registro para saber quantos serviços devem responder. O orquestrador pode ter uma lista de participantes e verificar quem já retornou.

4.2 Gerenciamento de Timeouts

• Em comunicação assíncrona, um serviço pode atrasar a resposta. Se o orquestrador esperar indefinidamente, o fluxo pode ficar preso. Definir timeouts e retentativas é crucial para evitar bloqueios.

4.3 Idempotência e Reentrância

• Mensagens podem ser entregues em duplicidade ou fora de ordem. Cada serviço deve tratar a requisição de forma idempotente, garantindo que processar novamente a mesma mensagem não gere inconsistências adicionais.

4.4 Observabilidade

• A execução paralela de múltiplos passos complica o rastreamento. É recomendável usar correlation IDs, logs centralizados e tracing distribuído para entender como cada serviço está se comportando.

5. Vantagens

1. Menor Latência Global
   • Ao disparar tarefas em paralelo, o tempo total de uma fase depende do serviço mais lento, não da soma de tempos de cada serviço.
2. Maior Flexibilidade
   • O orquestrador pode agrupar serviços que não têm dependências entre si em blocos paralelos, acelerando parte do processo.
3. Escalabilidade
   • Cada serviço consome mensagens em seu ritmo, podendo escalar horizontalmente se houver alta demanda.

6. Ilustração em Diagrama

Abaixo, um diagrama de sequência exemplificando o disparo e recepção de respostas em paralelo:

sequenceDiagram
    participant O as Orquestrador
    participant S1 as Serviço 1
    participant S2 as Serviço 2
    participant S3 as Serviço 3
Note over O: Inicia a fase em paralelo
O->>S1: Mensagem "Executar Etapa"
O->>S2: Mensagem "Executar Etapa"
O->>S3: Mensagem "Executar Etapa"
par Processamento
S1-->>O: Resposta (Sucesso ou Falha)
S2-->>O: Resposta (Sucesso ou Falha)
S3-->>O: Resposta (Sucesso ou Falha)
end

alt Alguma falha
    O->>S1: Compensar se S1 teve sucesso
    O->>S2: Compensar se S2 teve sucesso
    O->>S3: Compensar se S3 teve sucesso
    O-->>O: Registro de rollback e encerramento da fase
else Todas sucesso
    O->>O: Fase concluída, pronto para próxima
end

• Fan-out: O orquestrador envia instruções a cada serviço quase simultaneamente.
• Processamento Paralelo: Cada serviço trabalha em seu próprio ritmo, devolvendo sucesso/falha quando terminar.
• Decisão: Se ocorrer falha em qualquer serviço, o orquestrador inicia compensações nos outros que obtiveram sucesso.

7. Conclusão

O Parallel Saga (Assíncrono, Consistência Eventual, Orquestrado) oferece um modelo em que atividades podem ser executadas ao mesmo tempo, sob a supervisão de um orquestrador que coleta respostas e dispara compensações em caso de falhas. Esse formato explora:

• Comunicação via mensageria ou eventos, permitindo maior desacoplamento,
• Consistência baseada em “confirma e compensa”, aceitando estados intermediários,
• Coordenação central que gerencia fases paralelas, melhora a performance geral e organiza as lógicas de rollback.

Trata-se de um padrão útil para cenários onde várias operações podem rodar simultaneamente sem bloqueios, enquanto se mantém a segurança de uma “saga” — ou seja, a capacidade de reverter tudo, caso algo dê errado.