Issue 10016 · Sistemi distribuiti
Saga: gestire consistenza di business senza fingere un rollback perfetto
Quando un processo attraversa più servizi, la vera decisione non è “come annullare tutto”, ma come rendere espliciti stati intermedi, compensazioni e recovery.
· 5 min
Obiettivo
Coordinate long-running business transactions through local transactions, explicit intermediate states and compensating actions.
Come pensarla in pratica
Una SagaGlossarioSagaUna transazione lunga suddivisa in passi locali con recupero o compensazione espliciti.Apri la voce completa è utile quando il tuo processo di business attraversa più autorità transazionali e non vuoi legarti a una transazione distribuita. In pratica, significa progettare il flusso come una sequenza di transazioni locali, con stati intermedi persistiti e con un piano esplicito per gli errori. Il punto chiave è questo: non devi chiederti solo “come faccio andare avanti?”, ma anche “cosa è già successo, cosa posso compensare e chi decide il prossimo passo?”. Da architetto, conviene descrivere ogni step con quattro elementi minimi: effetto prodotto, stato salvato, compensazione disponibile e criterio di avanzamento. Se manca uno di questi elementi, la Saga sembra completa sulla carta ma poi fallisce nella parte operativa. Per evitare ambiguità, tratta ogni istanza come un caso di business con un proprio identificativo, una cronologia degli eventi e uno stato osservabile. Questo ti aiuta a gestire retryGlossarioRetryUn nuovo tentativo eseguito dopo un fallimento che potrebbe essere transitorio.Apri la voce completa, timeoutGlossarioTimeoutUn limite definito a quanto un’operazione attende prima di considerare il tentativo non riuscito.Apri la voce completa e ripartenze senza dover ricostruire tutto a mente o dai log. • Definisci il risultato di business finale, non solo la sequenza tecnica dei passi. • Persisti lo stato della Saga in modo esplicito e interrogabile. • Progetta idempotenzaGlossarioIdempotenzaLa proprietà per cui ripetere un’operazione non produce effetti aggiuntivi indesiderati.Apri la voce completa e riconciliazione per comandi e messaggi duplicati. • Se un timeout non prova il fallimento, verifica lo stato autorevole prima di ripetere l’azione.
Trade-off da valutare senza ideologia
La Saga sposta il problema dalla consistenza atomica alla gestione controllata dell’incoerenza temporanea. Il vantaggio è chiaro: meno lock, meno accoppiamento con un unico coordinatore transazionale, più resilienzaGlossarioResilienzaLa capacità di continuare a produrre risultati utili quando componenti falliscono o le condizioni degradano.Apri la voce completa tra servizi autonomi. Il costo è altrettanto reale: il sistema diventa più complesso da osservare, da testare e da spiegare al business. Con l’orchestrazione guadagni visibilità e controllo del flusso, ma concentri decisioni e responsabilità in un punto centrale. Con la coreografia preservi più autonomia ai team e riduci la dipendenza da un orchestratore, però perdi facilmente la vista end-to-end del processo e rischi di trasformare il troubleshooting in un lavoro di archeologia sugli eventi. C’è anche un trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa di prodotto, non solo tecnico. Se il business non accetta stati intermedi visibili oppure pretende rollback perfetti, la Saga è il pattern sbagliato. In quei casi è meglio riconsiderare il modello di processo o restringere l’invariant a una singola transazione locale. • Più autonomia e resilienza, ma anche più complessità operativa. • Più controllo con l’orchestrazione, ma anche più rischio di centralizzazione. • Più indipendenza con la coreografia, ma meno leggibilità del workflow complessivo. • Compensazione non significa rollback tecnico: può essere una nuova azione di business, non l’inverso perfetto.
Esempio enterprise realistico
Pensa a un ordine e-commerce che passa da OMS, pagamento, stock e fulfillment. L’OMS crea l’ordine, il PSP autorizza il pagamento, il sistema stock riserva la merce e il servizio di fulfillment apre la spedizione. Se il pagamento va a buon fine ma la prenotazione stock fallisce, non hai una “transazione fallita” in senso classico: hai un processo di business già parzialmente eseguito. A quel punto la Saga deve decidere se tentare una fonte stock alternativa, mettere l’ordine in attesa oppure compensare il pagamento con annullo o rimborso, a seconda dello stato reale e delle regole commerciali. Qui la qualità del design si vede subito: l’ordine conserva l’identificativo della Saga, ogni step registra l’esito, e gli operatori possono capire se il processo è in compensazione, in attesa o bloccato. Senza questa tracciabilità, il primo incidente serio diventa un problema di customer care, non solo di tecnologia. • Ordine creato, pagamento autorizzato, stock fallito: il sistema deve saper entrare in compensazione. • La compensazione dipende dallo stato business reale, non da un rollback teorico. • Serve osservabilitàGlossarioOsservabilitàLa capacità di comprendere il comportamento di un sistema a partire dai segnali che produce.Apri la voce completa di stato e ownership del recovery end-to-end.
Per approfondire
Fonti esterne autorevoli per approfondire il pattern Saga e il tema della consistenza distribuita. • Pattern: Saga — Chris Richardson — https://microservices.io/patterns/data/saga.html • Microservices Patterns — Chris Richardson (Manning, via O’Reilly) — https://www.oreilly.com/library/view/microservices-patterns/9781617294549/ • Data considerations for microservices — Microsoft Azure Architecture Center — https://learn.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations
Tag