Sagas e transações distribuídas

A saga é uma transação empresarial de longo prazo dividida em uma sequência de passos locais em serviços/armazenamento diferentes. Cada passo tem um efeito compensador que reverte o efeito do passo em uma falha parcial. Ao contrário de 2PC/3PC, as sagas não mantêm bloqueios globais e são adequadas para microsserviços, regiões multi e cargas elevadas, onde é permitido o eventual consistency.

1) Quando escolher a saga (e quando não)

• Processos empresariais de longo prazo/multi-up (encomenda → pagamento → reserva → entrega).
• Domínios e armazenamento diferentes onde não há transação compartilhada.
• Necessita de alta disponibilidade e escala horizontal.

• A atômica ACID firme é crítica (por exemplo, transferir grandes quantias dentro de um único registro).
• Não há compensabilidade clara (não é possível «reservar» ou cancelar o efeito).
• Restrições legais/regulatórias exigem isolamento rigoroso e invariante «instantâneo».

2) Modelos de sagas

1. Orquestração (Saga Orquestrador): O coordenador central controla os passos e compensações.

Vantagens: fluxo claro, controle de erros, telemetria simplificada.
Contras: ponto de centralização, risco de coordenador gordo.

2. Coreografia (Choreography): sem centro - os passos são iniciados por eventos («serviço A fez X → serviço B reage»).

Vantagens: conectividade fraca, escala simples.
Contras: É mais difícil monitorizar/desobstruir o fluxo, o risco de «estender» as regras.

3. TCC (Try-Confirm/Cancel): cada passo é «reserva» (Try), seguido de confirmação (Confirm) ou cancelamento (Cancel).

Mais perto do protocolo pseudo-dual, recursos administrados.
Contras: mais caro na implementação de interfaces; requer os horários dos detentores de Try.

3) Projetar o passo e compensar

Invariantes: configure claramente o que deve ser verdadeiramente «antes/depois» do passo (por exemplo, «saldo ≥ 0»).
Compensação ≠ transação reversa é uma ação lógica que anula o efeito empresarial (refund, release, restore).
Idempotidade: o passo e o compensador devem ser repetidos em segurança (por 'operation _ id').
Temporizações: cada passo tem deadline; atrasos iniciam compensações.
Efeitos não reembolsáveis: Registre-os separadamente (notificações, e-mails) e admita «best effort».

4) Coerência e ordem

Evolucional consistency: os usuários podem ver divergências temporárias; UX - com «espera «/spinners/estatais.
Ordem da chave: os passos de comutação são agrupados através de uma chave de negócio (order _ id) para organizar os eventos.
Deduplicação: guarde o registro de pagamento ('operation _ id' → status) com a TTL.

5) Transporte e confiabilidade

Outbox pattern: gravando um evento em uma tabela local de outbox dentro da mesma transação e, em seguida, publicando asincrona em um pneu.
Inbox/Idempotency store: No lado do consumidor, um registro de mensagens já processadas.
Exactly-once é eficaz: «outbox + idempotent consumer» dá a prática «exatamente uma vez».
DLQ: para mensagens «venenosas» com informações ricas em meta e em segurança.

6) Políticas de erro, retraí, backoff

Repetimos apenas os passos idempotantes; operações de gravação com 'Idempotency-Key'.
Backoff exponencial + jitter; limitação das tentativas e do deadline total da saga.
Em caso de degradação do sistema - Circuito Breaker e graceful degradation (por exemplo, cancelar a parte secundária de foz da saga).
Conflitos empresariais ('409') - repetição após negociação ou compensação e conclusão.

7) Orquestrador: responsabilidades e estrutura

• Rastreamento do estado da saga: 'PENDING → RUNNING → COMPENSATING → DONE/FAILED'.
• Planeamento de passos, deadline, timeouts, retraí.
• Roteiro de eventos e arranque compensações.
• Idempotidade das operações do coordenador (registro de comandos).
• Observabilidade: correlação 'saga _ id' em logs/trens/métricas.

• Tabelas «saga», «saga _ step», «commands», «outbox».
• Os índices são «saga _ id», «business _ key», «status», «next _ run _ at».

8) Coreografia: regras e proteção contra «coma da neve»

Contratos de eventos: esquemas e versionização (Avro/Pró/JSON Schema).
Semântica clara: "evento de fato" vs comando ".
«Failed »/« Compensate» publica um evento.
Alarme e alertas para «galhos infinitos».

9) TCC: detalhes práticos

Try: reserva de recurso com TTL.
Confirm: fixação, liberação de bloqueios temporários.
Cancel: reversão da reserva (sem efeitos colaterais).
Colecção de Garbage: Detecção automática de Try depois do TTL.
Idempotent Confirm/Cancel: repetição segura.

10) Exemplo (padrão verbal) - «Pedido de pagamento e entrega»

1. CreateOrder (local) → outbox: 'OrderCreated'.
2. PaymentService: reserva 'Try' (TCC); com o sucesso do → 'PaymentReserved', com a falha do → 'PaymentFailed'.
3. InventoryService: reserva do produto; com falta de → 'InventoryFailed'.
4. ShippingService: criação de uma slot de entrega (cancelável).
5. Se qualquer passo 'Failed' o orquestrador irá fazer uma compensação de volta: ' ' ' ' '.
6. Se estiver tudo bem ' ' n' .

11) Pseudocode orquestrador

pseudo startSaga(saga_id, order_id):
steps = [ReservePayment, ReserveInventory, BookShipment, ConfirmPayment]
for step in steps:
res = execWithRetry(step, order_id)
if!res.ok:
compensateInReverse(steps_done(order_id))
return FAIL return OK

execWithRetry(step, key):
for attempt in 1..MAX:
try:
return step.run(key)    # идемпотентно catch RetryableError:
sleep(backoff(attempt))
catch NonRetryableError:
return FAIL return FAIL

compensateInReverse(done_steps):
for step in reverse(done_steps):
step.compensate()       # идемпотентно

12) Observabilidade e SLO operacional

Tracing: uma única 'saga _ id', anotações 'step', 'attempt',' decision '(run/compensate/skip).

• Sucesso/erro de sagas (%), duração média, p95/p99.
• A proporção de sagas compensadas, as melhores causas das compensações.
• Filas/outbox de laje, retais a passos.
• Logi/auditoria: soluções do orquestrador, identificadores de recursos, chaves de negócio.

13) Testes e caos

Injecção de erros em cada etapa: timeouts, '5xx', conflitos de negócios.
Out-of-order eventos, duplicados, omissões (drop).
Longas caudas de latência → verificação de deadline e compensações.
Sagas em massa → teste WFQ/DRR e caps em filas, falta de «head-of-line blocking».
Redrave do DLQ a passos e a saga inteira.

14) Multi-tenência, regiões, conformidade

Tags 'tenant _ id/place/region' em eventos e armazenamentos de sagas.
Residency: dados/eventos não saem da região; sagas cruzadas-regionais projetem como federações de sagas locais + eventos agregadores.
Priorização: As sagas VIP têm um maior peso; isolamento dos worker per tenant.

15) Folha de cheque antes de vender

• Cada passo tem um compensador claro, ambos idimpotentes.
• Modelo selecionado: Orquestra/coreografia/SS; os limites da responsabilidade são descritos.
• Outbox/Inbox foram incorporados, deduzindo por 'operation _ id'.
• Políticas de retrações: backoff com jitter, limites de tentativas e o compartilhamento da saga.
• Os contratos de eventos são versionizados, há validação do esquema.
• O DLQ e o redrave seguro estão configurados.
• Telemetria: métricas, trailing, correlação 'saga _ id'.
• Playbooks operacionais: cancel manual/force-conferm, descodificar as sagas «dependentes».
• Testes de caos e carga passam, SLO/orçamento de erros definidos.

16) Erros típicos

Não há compensador ou é «imundo» (tem efeitos secundários).
Não há idimpotência/dedução - duplos e «balanços» de estados.
«Saga na saga» sem limites claros - ciclos e bloqueios mútuos.
Não há deadline, sagas «eternas» e fugas de recursos.
O orquestrador guarda um estado de «memória» sem estoque sustentável.
Uma coreografia sem centro de telemetria → falhas «invisíveis».
UX opaco: os usuários não veem os estados intermediários.

17) Receitas rápidas

Clássico SaaS: Orquestra + outbox/inbox, backoff exponencial, DLQ, estadias da saga em UI.
Invariantes fortes para o recurso: TCC com TTL de reserva e GC Cancel.
Alto volume/carga: coreografia de eventos + idempotidade rigorosa e métricas à chave.
Região Multi: sagas locais + equipamentos finais; evitar bloqueios globais.

Conclusão

As sagas são uma forma de obter uma coerência previsível em sistemas distribuídos sem bloqueios globais. Compensadores claros, idempotidade, entrega confiável (outbox/inbox), disciplina de temporizadores e retrações, além de telemetria e playbooks - a chave para garantir que os processos complexos de negócios permaneçam sustentáveis e legíveis com o aumento da carga de trabalho, o número de serviços e geografias.