Phone Tag Saga: Síncrona, Atômica e Coreografada

Dentro dos padrões que combinam comunicação, consistência e coordenação em Sagas, há um modelo em que se busca consistência “atômica” usando chamadas síncronas, mas adotando coreografia como forma de coordenação — o que se costuma chamar de Phone Tag Saga. Neste artigo, vamos compreender as características desse padrão, suas diferenças em relação a uma Epic Saga (que usa orquestração) e como o fluxo se desenvolve quando cada serviço aciona o próximo passo diretamente.

1. Contexto e Conceito

Em Sagas, a ideia geral é que cada etapa confirme sua operação local e, em caso de falha posterior, exista a possibilidade de compensação. Na Phone Tag Saga, há três elementos principais:

1. Comunicação Síncrona
   Cada serviço envia requisições a outro serviço e aguarda resposta, sem utilizar mensageria ou eventos assíncronos.
2. Consistência Atômica (ou quase atômica)
   O objetivo é que cada suboperação ocorra de modo a minimizar estados intermediários, permitindo que uma falha desencadeie a compensação rápida de etapas anteriores.
3. Coreografia
   Em vez de um orquestrador central, cada serviço conhece a lógica de quem chamar em seguida ou a quem sinalizar falha, formando uma cadeia de chamadas entre os participantes.

Esse “tag” no nome sugere a ideia de serviços “passando a bola” de um para o outro, de maneira síncrona, até que o fluxo seja concluído ou falhe.

2. Principais Diferenças em Relação ao Epic Saga

• Coordenação:
  • Epic Saga (orquestração): um componente central orquestra a sequência.
  • Phone Tag Saga (coreografia): cada serviço chama o próximo passo ou retorna sinais de falha para o anterior.
• Ponto de Controle:
  • Epic Saga: O orquestrador decide a ordem, monitora o status de cada etapa e aciona compensações.
  • Phone Tag Saga: As etapas comunicam-se diretamente, sem um coordenador único, baseando-se em fluxos predeterminados.

No caso da Phone Tag, existe uma tentativa de manter a aparência de atomicidade, mas cada serviço precisa ter conhecimento sobre quem invocar (próximo passo) ou como disparar compensações nas etapas passadas.

3. Funcionamento Passo a Passo

3.1 Definindo a Sequência de Chamadas

Suponha um processo com três serviços (S1, S2, S3). Na Phone Tag Saga, o fluxo seria algo assim:

1. Serviço S1 recebe a solicitação inicial (por exemplo, via endpoint exposto).
2. Ao finalizar sua operação local, S1 chama S2 de forma síncrona, passando dados e aguardando resposta.
3. Se S2 concluir com sucesso, chama S3 e aguarda a resposta.
4. Em caso de falha em S3, há um mecanismo de sinalização para que S2 inicie compensação local e também avise S1 a compensar.

3.2 Compensações Encadeadas

Caso um passo falhe:

• O serviço que detectou a falha retorna sinal de erro ao anterior.
• Esse serviço anterior executa sua compensação (se houver) e pode ainda sinalizar outro serviço anterior, gerando um efeito em cascata de reversões.

Como não há orquestrador único, é necessário que os serviços troquem informações sobre a etapa em que estão, para saber o que deve ser compensado.

3.3 Atomicidade “em Cadeia”

A ideia de “atômica” aqui significa que cada serviço efetiva suas mudanças (confirmando localmente) logo após a chamada, e se alguma etapa seguinte falhar, o serviço chamador se encarrega de iniciar reversões anteriores. O objetivo é reduzir o tempo em que o sistema pode ficar em inconsistência.

4. Exemplos de Uso

4.1 Criação de Pedido em Duas Etapas

1. Serviço de Itens (S1): Cadastra os itens do pedido.
2. Serviço de Pagamento (S2): Recebe a chamada de S1 para processar o pagamento.
3. Se S2 tiver sucesso, o fluxo pode encerrar ou chamar S3. Caso contrário, S2 sinaliza erro para S1, que compensa o cadastro de itens.

4.2 Fluxo Simples de Reserva

1. Serviço de Transporte (S1): Reserva um transporte.
2. Serviço de Hotel (S2): Ao terminar, chama o serviço de hotel para confirmar estadia.
3. Se falhar, avisa S1 para liberar a reserva.
4. Se sucesso, finaliza o processo sem um orquestrador central.

5. Considerações de Projeto

5.1 Conhecimento Mútuo dos Serviços

Na Phone Tag Saga, cada serviço deve saber:

• Quem chamar em caso de sucesso (o próximo da cadeia).
• A quem avisar em caso de falha (o serviço anterior ou toda a cadeia).

Isso implica que cada participante armazene alguma lógica de fluxo ou roteamento, definindo como prosseguir ou recuar.

5.2 Gerenciamento de Timeout

Como as chamadas são síncronas, cada serviço deve tratar a possibilidade de tempo excessivo de resposta. Um timeout pode ser interpretado como falha, disparando a compensação.

5.3 Complexidade de Rastreamento

Sem um orquestrador central, o rastreamento das etapas do fluxo depende de logs e correlação entre serviços. Cada um deve registrar qual etapa está executando, quem chamou e qual o próximo passo esperado.

6. Exemplo Ilustrativo

sequenceDiagram
    autonumber
    participant A as Serviço A
    participant B as Serviço B
    participant C as Serviço C

    A->>B: Requisição Síncrona (Etapa 2)
    alt Falha em B
        B-->>A: Indica Erro
        A->>A: Compensa Etapa 1
    else Sucesso
        B-->>A: OK
        A->>C: Chama C?
        C-->>A: OK ou Erro
        alt Falha em C
            A->>B: Solicita Compensação?
        end
    end

Neste diagrama simplificado, o Serviço A inicia o fluxo, chama B e recebe respostas, mas não há um elemento orquestrador distinto. É A quem dispara chamadas e coordena respostas, podendo envolver C ou outros serviços, de acordo com as regras estabelecidas.

7. Finalidade

A Phone Tag Saga visa oferecer:

• Comunicação Síncrona entre etapas,
• “Atomicidade” via confirmações e reversões encadeadas,
• Coreografia, sem orquestrador central.

Cada ambiente pode optar por esse modelo em situações onde se deseja uma coordenação ponto a ponto, com cada serviço cuidando de quem chamar ou como compensar, mantendo uma sensação de transação encadeada entre serviços.

8. Conclusão

O Phone Tag Saga é um padrão em que a busca por consistência atômica combina chamadas síncronas e a ausência de um orquestrador central. Cada serviço sabe a quem ligar na próxima etapa e como iniciar compensações se algo der errado posteriormente. Essa abordagem, centrada em coreografia, requer:

• Definição clara de quem chama quem e em qual ordem,
• Mecanismos de compensação local que possam ser disparados por notificações de falha,
• Capacidades de rastreamento para identificar em que etapa o fluxo se encontra.

Trata-se de uma forma de implementar Sagas, diferente do “Epic Saga” (que usa orquestração), mantendo o foco em sincronismo e minimizando estados intermediários, mas distribuindo a lógica de coordenação entre os serviços participantes.