Cos'è il saga pattern nei microservizi?

Il saga pattern è una tecnica per gestire una transazione che attraversa più servizi, ognuno con il proprio database, quando non esiste un meccanismo di commit unico che li copra tutti insieme. La transazione viene scomposta in una sequenza di passi locali, ciascuno con la sua azione di compensazione: se un passo a metà sequenza fallisce, il sistema non fa un rollback nel senso classico, che presuppone poter annullare come se nulla fosse accaduto, ma esegue all'indietro le compensazioni dei passi già completati, azioni che ne annullano gli effetti nel mondo reale. Il termine nasce dal paper Sagas di Hector Garcia-Molina e Kenneth Salem, presentato al SIGMOD 1987, pensato per transazioni di lunga durata sui database relazionali dell'epoca. Nei microservizi la stessa idea risolve un problema quotidiano: tenere database separati per servizio, ma far avanzare insieme, o disfare insieme, un ordine, un pagamento e una spedizione.

Orchestrazione, coreografia e il limite del rollback semantico

Una saga si implementa in due modi. Nell'orchestrazione un coordinatore centrale conosce l'intera sequenza, chiama ogni servizio nell'ordine previsto e decide quando invocare le compensazioni: più facile da seguire e da debuggare, ma introduce un componente che tutti i servizi devono conoscere. Nella coreografia non esiste un coordinatore: ogni servizio pubblica un evento a fine del proprio passo e reagisce agli eventi altrui, un'architettura più disaccoppiata ma più difficile da capire a posteriori quando qualcosa va storto, perché la sequenza esiste solo nella somma dei comportamenti locali. In entrambi i casi vale lo stesso limite: la compensazione è un rollback semantico, non un annullamento. Un pagamento si può stornare, un ordine si può cancellare, ma un'email già inviata non si può far tornare non letta, e una spedizione già partita richiede un ritiro, non una cancellazione pulita. Le compensazioni vanno inoltre progettate per essere ripetibili in sicurezza, la stessa disciplina descritta in idempotenza e backfill, perché un retry dopo un timeout di rete non deve stornare due volte lo stesso pagamento.

Un esempio enterprise concreto

Un e-commerce riceve un ordine gestito da tre servizi: pagamento, magazzino, spedizione. Il pagamento viene autorizzato, il magazzino riserva la merce, ma la spedizione fallisce perché il corriere non copre quel codice postale. La saga non lascia il sistema in uno stato ambiguo: rilascia la riserva di magazzino e rimborsa il pagamento già autorizzato, nell'ordine inverso rispetto a quello in cui i passi erano avvenuti. Nessuna delle tre operazioni era una singola transazione ACID che copriva tutti e tre i database, le garanzie descritte in ACID restano valide solo dentro il confine di ogni singolo servizio: la saga è il meccanismo che ricompone un esito coerente attorno a quel confine, non dentro di esso.

Perché conta per chi decide

Lo stesso problema torna, quasi identico, nei workflow agentici: un agente che ha già inviato un'email, emesso un ordine di acquisto o aperto un ticket con un fornitore, e poi fallisce al passo successivo, deve disfare azioni parziali già avvenute nel mondo reale, non in un database che si può rimettere a posto con una query. Il punto scomodo è lo stesso di cui sopra: alcune azioni non sono compensabili, e nessuna orchestrazione software lo cambia. Chi progetta questi flussi dovrebbe collocare le azioni irreversibili il più tardi possibile nella sequenza, dopo tutti i passi che si possono ancora annullare, oppure metterle dietro un'approvazione umana prima che l'azione esca dal sistema. È una decisione di design che vale la discussione a inizio progetto, perché scoprirla dopo il primo incidente in produzione costa la fiducia di chi doveva firmare quell'approvazione a monte.