Saga Pattern — Cheat Sheet

Tag: microservices, architecture, transactions, event-driven, distributed

Livello: avanzato

TL;DR: Pattern per gestire transazioni distribuite tra più microservizi tramite una sequenza di transazioni locali, utilizzando messaggi asincroni e compensazioni per i rollback.

Concetti chiave

Una Saga è una sequenza di transazioni locali: ogni step aggiorna i dati all'interno di un singolo servizio.

Ogni transazione locale completata pubblica un evento o messaggio che innesca lo step successivo.

In caso di fallimento di uno step, vengono eseguite "transazioni di compensazione" per annullare le modifiche dei passaggi precedenti.

Coreografia (Choreography): i servizi comunicano scambiandosi eventi in modo decentralizzato, senza un coordinatore.

Orchestrazione (Orchestration): un componente centrale (orchestratore) dirige il flusso e dice ai partecipanti cosa eseguire.

Risolve i problemi di scalabilità e di blocco delle risorse del 2PC (Two-Phase Commit) nei sistemi distribuiti.

Accetta il compromesso della consistenza eventuale (eventual consistency) rinunciando all'isolamento ACID tradizionale.

L'idempotenza delle operazioni (soprattutto delle compensazioni) è un requisito essenziale.

Domande tipiche e risposte pronte

Q: Quando dovresti usare il Saga Pattern invece del Two-Phase Commit (2PC)?R: Lo uso in architetture a microservizi con database indipendenti. Il 2PC blocca i record e non scala bene; la Saga favorisce la disponibilità del sistema tramite la consistenza eventuale.

Q: Qual è la differenza tra Coreografia e Orchestrazione in una Saga?R: Nella coreografia ogni servizio reagisce autonomamente agli eventi, ottima per flussi semplici. Nell'orchestrazione un controller centrale gestisce lo stato e i rollback, essenziale quando gli step sono numerosi e complessi.

Q: Come gestisci il fallimento di