Saga Pattern: coordinare transazioni distribuite con compensazioni esplicite

Tipo

Concetto

Una Saga rappresenta una transazione di business che attraversa più servizi o sistemi senza poter essere racchiusa in un’unica transazione ACID distribuita. Ogni partecipante esegue una propria transazione locale e comunica il risultato al passo successivo. Quando un passaggio fallisce, il sistema non annulla automaticamente tutte le operazioni precedenti: deve eseguire azioni compensative progettate esplicitamente per riportare il processo in uno stato di business accettabile. ## Il problema architetturale In un sistema distribuito, processi come creazione dell’ordine, autorizzazione del pagamento, prenotazione dello stock e organizzazione della spedizione coinvolgono componenti che possiedono dati e transazioni differenti. Una transazione distribuita tradizionale può introdurre forte accoppiamento, lock prolungati, scarsa disponibilità e dipendenza da tecnologie coordinate. Una Saga accetta invece che il processo attraversi stati intermedi osservabili e che la consistenza venga raggiunta attraverso passi locali e recovery di business. ## Compensazione non significa rollback tecnico Una compensazione è una nuova operazione di business che controbilancia un effetto precedente. Non è necessariamente l’inverso perfetto della transazione iniziale. Rilasciare una prenotazione di stock può compensare una reservation. Emettere un rimborso può compensare un pagamento già acquisito. Annullare una spedizione può essere impossibile se il pacco è già partito: in quel caso il processo deve entrare in un percorso operativo diverso. Per questo ogni passo della Saga deve dichiarare: - l’effetto prodotto; - il risultato persistito; - il successivo passo consentito; - la compensazione disponibile; - i casi in cui la compensazione non è possibile; - chi possiede il recovery manuale. ## Orchestrazione e coreografia In una Saga orchestrata, un componente esplicito conosce il workflow, invia i comandi ai partecipanti e decide come proseguire o compensare. Questo migliora visibilità e controllo, ma concentra logica e responsabilità nell’orchestratore. In una Saga coreografata, i partecipanti reagiscono agli eventi prodotti dagli altri sistemi. Questo può preservare maggiore autonomia, ma rende più difficile comprendere il workflow completo, diagnosticare i blocchi e governare l’evoluzione del processo. La scelta non dovrebbe essere ideologica. Dipende da complessità del processo, numero dei partecipanti, bisogno di visibilità, frequenza delle modifiche e ownership organizzativa. ## Requisiti di affidabilità I messaggi e i comandi della Saga possono essere consegnati più volte. I partecipanti devono quindi essere idempotenti oppure riconoscere le richieste già elaborate. Ogni istanza della Saga deve avere un identificativo stabile e uno stato persistito. Il sistema deve poter distinguere almeno stati come avviata, in esecuzione, completata, in compensazione, compensata, fallita e in attesa di intervento. Timeout, retry, dead letter, ordine dei messaggi e risposte ambigue devono essere parte del design. Un timeout non dimostra che l’operazione non sia avvenuta: prima di ripeterla può essere necessario interrogare lo stato autorevole del partecipante. ## Quando usarla Una Saga è appropriata quando: - un processo di business attraversa più autorità transazionali; - non è possibile o desiderabile usare una transazione distribuita; - gli stati intermedi sono accettabili e comprensibili; - esistono compensazioni o percorsi operativi per i fallimenti; - il workflow deve continuare anche quando alcuni componenti sono temporaneamente indisponibili. ## Quando non usarla Non introdurre una Saga quando una singola transazione locale può proteggere l’intero invariant oppure quando il processo è semplice e sincrono. È una scelta rischiosa quando il business pretende rollback perfetti, gli stati intermedi non sono accettabili, le compensazioni non sono definite oppure nessun team possiede il recovery end-to-end. ## Errori comuni - Disegnare solo la sequenza positiva e ignorare compensazioni e stati incerti. - Trattare una compensazione come un rollback tecnico garantito. - Non persistere lo stato della Saga. - Affidarsi a messaggi exactly-once invece di progettare idempotenza. - Usare coreografia per workflow complessi senza una vista end-to-end. - Centralizzare ogni decisione nell’orchestratore fino a trasformarlo in un nuovo monolite. - Non prevedere osservabilità, riconciliazione e intervento manuale. ## Esempio enterprise Un ordine e-commerce richiede quattro passaggi: 1. creazione dell’ordine nell’OMS; 2. autorizzazione del pagamento; 3. prenotazione dello stock; 4. apertura del processo di fulfillment. Se il pagamento viene autorizzato ma la prenotazione dello stock fallisce, la Saga può tentare fonti alternative, mettere l’ordine in attesa oppure compensare il pagamento tramite annullamento o rimborso. La scelta dipende dallo stato reale del pagamento e dalle regole commerciali. Il sistema deve conservare l’identificativo del processo, gli esiti dei singoli partecipanti e l’evidenza delle compensazioni effettuate. ## Domande per il Solution Architect Prima di adottare una Saga, chiedi: - Quale risultato di business definisce il completamento? - Quali stati intermedi saranno visibili agli utenti e agli operatori? - Quale compensazione corrisponde a ogni passo già completato? - Quali operazioni sono irreversibili? - Chi possiede il workflow end-to-end? - Come vengono gestiti timeout e risultati ambigui? - Come si osservano le istanze bloccate? - Quando è necessario un intervento umano?