Saghe e transazioni distribuite

La saga è una transazione aziendale a lungo termine suddivisa in una sequenza di passaggi locali in diversi servizi/storage. Ogni passo ha un'azione di compensazione che ripristina l'effetto del passo in caso di fallimento parziale. A differenza di 2PC/3PC, le sagome non mantengono blocchi globali e sono adatte per microservizi, regioni multi e carichi di lavoro elevati in cui è consentito l'eventual consistency.

1) Quando selezionare una saga (e quando no)

• Processi aziendali a lungo termine/multi-aging (ordine, pagamento, riserva e consegna).
• Domini e archivi diversi in cui non esiste una transazione condivisa.
• Necessità di elevata disponibilità e scalabilità orizzontale.

• La solidità ACID è critica (ad esempio, il trasferimento di importi elevati all'interno di un singolo registro).
• Nessuna compensabilità chiara (non è possibile prenotare o annullare l'effetto).
• Le restrizioni legali/regolatorie richiedono un isolamento rigoroso e un invariante «istantaneo».

2) Modelli di saghe

1. Orchestrazione (Saga Orchestrator) - Il coordinatore centrale controlla passi e compensi.

I vantaggi sono il flusso chiaro, il controllo degli errori, la telemetria semplificata.
Punti di centralizzazione, rischio di coordinatore «grasso».

2. Coreografia - Nessun centro - Le fasi sono avviate dagli eventi («Il servizio A ha reso X il servizio B risponde»).

I vantaggi sono la scarsa connettività, la semplice scalabilità.
Contro: più difficile monitorare/ritardare il flusso, rischio di «espansione» delle regole.

3. TCC (Try-Confirm/Cancel) - Ogni passo è «ridondanza», quindi conferma (Confirm) o annulla (Cancel).

Pro: più vicino al protocollo pseudonimo-dual-fase, risorse gestite.
Meno: più costoso nell'implementazione delle interfacce richiede timeout dei titolari di Try.

3) Progettazione del passo e della compensazione

Invarianti: definisci chiaramente ciò che deve essere vero prima/dopo del passo (ad esempio "residuo" 0 ").
Compensazione di una transazione inversa: si tratta di un'azione logica che elimina gli effetti aziendali (refund, release, restore).
Idampotenza: sia il passo che il compensatore devono ripetersi in sicurezza (in «operation _ id»).
Timeout: ogni passo ha deadline; Il ritardo avvia i risarcimenti.
Effetti non restituiti: fissarli separatamente (notifiche, e-mail) e tollerare'best effort '.

4) Coerenza e ordine

Eventual consistency - Gli utenti possono vedere le soluzioni temporanee. UX - con «attesa «/spinner/states.
Ordine chiave - Raggruppare i passaggi di switch in chiave aziendale (order _ id) per organizzare gli eventi.
Deduplicazione: memorizza il registro dei guadagni ('operation _ id' → stato) con TTL.

5) Trasporti e affidabilità

Outbox pattern: scrittura di un evento nella tabella locale outbox all'interno della stessa transazione, quindi pubblicazione asincrona nel bus.
Inbox/Idempotency store: il registro dei messaggi già elaborati è al fianco del consumatore.
Exactly-once è efficace: «outbox + idempotent consumer» dà la pratica «esattamente una volta».
DLQ: per messaggi «velenosi» con informazioni ricche di meta-informazioni e ridrive sicuro.

6) Regole di errore, retrai, backoff

Ripetiamo solo i passaggi idempotenti; operazioni di scrittura con «Idempotency-Key».
Backoff esponenziale + jitter; limitare i tentativi e la deadline totale della saga.
In caso di degrado di sistema - Circuito Breaker e graceful degradation (ad esempio, annullare la parte secondaria della saga fund).
Conflitti aziendali ('409') - Ripetizione dopo aver negoziato o compensato e completato.

7) Orchestratore: responsabilità e struttura

• Monitoraggio dello stato della saga: «PENDING RUNNING» COMPENSATING «DONE/FAILED».
• Pianificazione dei passi, deadline, timeout, retrai.
• Routing degli eventi e avvio dei rimborsi.
• Idampotenza delle operazioni di coordinatore (registro dei comandi).
• Osservabilità: correlazione'saga _ id 'in/trailer/metriche.

• Tabelle «saga», «saga _ step», «commands», «outbox».
• Gli indici sono «saga _ id», «business _ key», «status», «next _ run _ at».

8) Coreografia: regole e protezione contro il «coma delle nevi»

Contratti eventi: schemi e versioning (Avro/Proto/JSON Schema).
Semantico chiaro: "evento di fatto" vs comando ".
Failed della catena: il servizio, dopo aver rilevato un'incongruenza, pubblica l'evento «Failed »/« Compensate».
Allarmi e alert per «loop infiniti».

9) TCC: dettagli pratici

Try - Riserva della risorsa con TTL.
Confirm: fissa, libera blocchi temporanei.
Cancel - Reimpostazione della riserva (senza effetti collaterali).
Garbage collection - Try automatico dopo TTL (Idempotent Cancel).
Confirm/Cancel Idempotent: ripetizione sicura.

10) Esempio (schema verbale) - Ordine di pagamento e consegna

1. CreateOrder (locale) → outbox: «OrderCreated».
2. PaymentService: riserva «Try» (TCC); Con il successo di « », con il fallimento di « ».
3. InventoryService: riserva del prodotto; in caso di insufficienza dì ".
4. ShippingService - Crea uno slot di spedizione (da annullare).
5. Se qualsiasi passo dì Failed ", l'orchestratore fa scattare i risarcimenti in ordine inverso.
6. Se tutto va bene.

11) Pseudocode orchestratore

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) Osservabilità e SLO operativi

Tracing: un'unica «saga _ id», annotazioni «step», «attempt», «decise» (run/compensate/skip).

• Successo/errore delle saghe (%), durata media, p95/p99.
• La percentuale di saghe compensate, la più alta causa di risarcimento.
• Code/outbox lagi, retrai per passo.
• Logi/verifiche: soluzioni orchestrali, ID risorse, chiavi aziendali.

13) Test e caos

Iniezione di errori in ogni passo: timeout, '5xx', conflitti aziendali.
Out-of-order eventi, duplicati, omissioni (drop).
Lunghe code di latitanza per controllare deadline e risarcimenti.
Le saghe di massa controllano WFQ/DRR e caps in coda, senza «head-of-line blocking».
Redrave del DLQ per passo e per tutta la saga.

14) Multi-tenenza, regioni, conformità

Tag «tenant _ id/plan/region» negli eventi e negli archivi delle saghe.
Residency: dati/eventi non abbandonano la regione; le saghe crocifissi progettate come federazioni di saghe locali + eventi di aggregazione.
Priorità: le saghe VIP hanno più peso in quota; isolamento dei worker per tenant.

15) Foglio di assegno prima della vendita

• Ogni passo ha un compensatore chiaro, entrambi idipotenti.
• Modello selezionato: orchestrazione/coreografia/TSS; I limiti della responsabilità sono descritti.
• Outbox/Inbox incorporati, deduplicazione per «operation _ id».
• Policy retraes: backoff con jitter, limiti di tentativo e deadline generale della saga.
• I contratti di eventi sono versionati, c'è la validazione dello schema.
• Il DLQ e il redrave sicuro sono configurati.
• Telemetria: metriche, tracking, correlazione «saga _ id».
• Playbooks operativi: cancel manuale/forza-confirm, decifrazione delle saghe «dipendenti».
• Test di caos e carico sono in corso, SLO/bilancio degli errori definiti.

16) Errori tipici

Nessun compensatore o «impuro» (ha effetti collaterali).
Nessuna idimpotenza/deducibilità - doppie e altalena degli stati.
«Saga in saga» senza confini evidenti - cicli e blocchi reciproci.
Niente deadline per le saghe «eterne» e la fuga di risorse.
L'orchestratore conserva lo stato di memoria senza uno store sostenibile.
Una coreografia senza un centro di telemetria è un guasto invisibile.
UX opaco: gli utenti non vedono gli stati intermedi.

17) Ricette veloci

Classica SaaS: orchestrazione + outbox/inbox, backoff esponenziale, DLQ, stato della saga in UI.
Forti invarianti per la risorsa: TCC con TTL di riserva e GC Cancel.
Alto volume/carico di lavoro: coreografia degli eventi + idampotenza rigorosa e metriche sulla chiave.
Regione Multi: saghe locali + aggregazioni finali; evitare blocchi globali.

Conclusione

Le sagre sono un modo per ottenere una prevedibile coerenza nei sistemi distribuiti senza blocchi globali. Compensatori chiari, idipotenza, spedizioni affidabili (outbox/inbox), disciplina dei timeout e dei retrai, più la telemetria e le playbook sono la chiave per garantire che i processi aziendali complessi rimangano stabili e leggibili con l'aumento del carico di lavoro, il numero di servizi e le geografie.