Anthology Saga: Assíncrono, Consistência Eventual e Coreografado · kusmin

Dentro do espectro de possíveis combinações em Sagas para microserviços, o Anthology Saga mescla comunicação assíncrona, consistência eventual e coordenação via coreografia (sem um orquestrador único). A palavra “Anthology” remete à ideia de histórias independentes que, no final, convergem para formar um conjunto coerente. Analogamente, aqui cada serviço trabalha autonomamente com trocas de eventos, e o sistema, ao longo do tempo, atinge um estado consistente via compensações.

1. Conceito Fundamental

Comunicação Assíncrona
- Os serviços se comunicam por meio de mensagens (ex.: filas, tópicos, pub/sub), sem bloqueio de requisições diretas.
Consistência Eventual
- Cada serviço confirma suas operações localmente. Em caso de falhas, eles iniciam ou respondem a compensações, ocorrendo um período de inconsistência até que tudo se estabilize.
Coreografia
- Não há um orquestrador central. Cada serviço decide as ações subsequentes (ou de rollback), reagindo aos eventos provenientes dos demais.

1.1 Por Que “Anthology”?

Tal como uma coletânea de histórias que se entrelaçam para formar um enredo maior, no Anthology Saga cada “peça” (serviço) possui seu próprio fluxo, mas esses fluxos interagem via eventos para alcançar um objetivo global. É uma forma de unir várias operações autônomas em prol de um resultado comum, mas sem uma entidade única controladora.

2. Funcionamento Geral

Publicação de Eventos
- Quando um serviço completa uma operação, publica um evento de “sucesso” ou “falha” num broker (fila, tópico, streaming).
Reação pelos Demais Serviços
- Outros serviços, inscritos nesses eventos, decidem como proceder. Se um deles receber “falha” de outro participante, pode disparar sua compensação. Se receber “sucesso”, pode executar sua etapa seguinte.
Estabilização via Compensações
- Se qualquer participante sinalizar falha, diversos serviços podem iniciar rollbacks, cada um no seu ritmo. A consistência final só é atingida após todos concluírem as devidas compensações.

2.1 Modelo “Confirma e Compensa”

Cada serviço registra localmente seu status (por exemplo, “pendente”, “concluído”) após executar as ações. Caso um evento posterior indique que algo deu errado em outro serviço, ou que o processo como um todo não pode prosseguir, cada serviço que já confirmou é notificado para reverter o que foi feito. O tempo de reação e processamento desses eventos cria uma janela de inconsistência.

3. Exemplo de Cenário

Imagine um processo em que três serviços independentes se organizam para entregar um produto digital:

Serviço de Licenciamento (gera chaves de acesso)
Serviço de Pagamento (processa fatura, transação financeira)
Serviço de Integração Externa (envia dados a parceiros, se a venda for confirmada)

Fluxo em Anthology Saga:

O Serviço de Licenciamento conclui a geração da chave e publica “ChaveGerada” (sucesso) ou “LicencaFalhou” (falha).
Serviço de Pagamento está inscrito nesse evento. Ao receber “ChaveGerada”, decide efetivar a cobrança e, em caso de sucesso, publica “PagamentoOK”. Se falhar, publica “PagamentoErro”.
Serviço de Integração Externa reage tanto a “ChaveGerada” quanto a “PagamentoOK”. Se ambos chegarem como sucesso, inicia sua etapa. Se detectar “PagamentoErro” em qualquer ponto, dispara seu rollback para descartar as integrações pendentes.

Em todos os casos, não existe um orquestrador único, mas sim serviços que se “escutam” mutuamente e reagem. Após uma série de eventos, o sistema converge para um estado final — seja sucesso total ou compensado.

4. Ilustração em Diagrama (Mensageria)

flowchart LR
    A((Serviço Licenciamento)) -- Evento "LicencaOk" --> Broker
    A -- Evento "LicencaFalhou" --> Broker
B((Serviço Pagamento)) -- inscrito em "LicencaOk" / "LicencaFalhou"
B -- Evento "PagamentoOK" / "PagamentoErro" --&gt; Broker

C((Serviço IntegracaoExterna)) -- inscrito em "LicencaOk" e "PagamentoOK"
C -- Evento "IntegracaoSucesso" / "IntegracaoFalha" --&gt; Broker

Broker((Broker de Eventos)) -- Distribui --&gt; A
Broker((Broker de Eventos)) -- Distribui --&gt; B
Broker((Broker de Eventos)) -- Distribui --&gt; C

Cada serviço publica e consome eventos, tomando suas decisões de avançar ou retroceder com base no que “ouve” do broker. Não há um componente central que saiba de todo o fluxo.

5. Pontos de Atenção

5.1 Determinar Quais Eventos São Necessários

Em coreografia assíncrona, cada serviço precisa conhecer as condições em que se espera receber notificações e quais eventos deve publicar. É importante evitar “tempestades de eventos” irrelevantes.

5.2 Idempotência e Anti-Duplicação

Eventos podem chegar duplicados ou fora de ordem. Cada serviço deve ser capaz de processar mensagens repetidas sem gerar efeitos colaterais indevidos (ex.: aplicar uma mesma alteração duas vezes).

5.3 Estrutura de Compensação Distribuída

Se o Serviço de Pagamento falhar, o Serviço de Licenciamento pode precisar revogar a chave gerada. O Serviço de Integração Externa pode precisar anular envios. Tudo acontece sem que haja alguém ordenando diretamente cada rollback, e sim por meio de eventos de falha que disparam ações de reversão.

5.4 Monitoramento e Tracing

Sem orquestrador, o rastreamento de quem fez o quê demanda logs enriquecidos e tracing distribuído. Isso inclui correlação de IDs em cada evento para seguir a cadeia de ações nos serviços.

6. Vantagens e Desafios

Vantagens:

Alta Escalabilidade: Cada serviço recebe apenas os eventos de seu interesse, podendo escalar horizontalmente para lidar com alto volume.
Baixo Acoplamento: A adição ou remoção de serviços pode ser feita com pouca interferência nos demais, contanto que publiquem/assinem eventos adequados.

Desafios:

Complexidade de Rastreio: Entender o estado global é mais difícil sem um orquestrador.
Protocolo de Eventos: É preciso definir cuidadosamente quais eventos serão produzidos, como eles se relacionam e quando disparam as compensações.
Inconsistência Temporária: Durante compensações, o sistema pode permanecer em estado divergente por períodos prolongados.

7. Conclusão

O Anthology Saga (Assíncrono, Consistência Eventual, Coreografado) dá liberdade para cada serviço orquestrar sua própria lógica de transações locais e compensações em resposta a eventos dos outros. Esse modelo:

Dispensa um orquestrador central,
Depende de uma troca de eventos bem definida,
Aceita ficar em estados intermediários até que as compensações se apliquem por completo.

Esse nível de autonomia e desacoplamento pode ser vantajoso em ecossistemas grandes e heterogêneos, onde a coordenação centralizada se tornaria um gargalo. Por outro lado, exige grande disciplina de engenharia para manter a observabilidade, a idempotência e a clareza no design dos eventos de sucesso/falha. Com um design bem estruturado, o Anthology Saga atende processos distribuídos que evoluem de forma colaborativa e se recuperam de falhas graças a um ecossistema de mensagens.