En el subcapítol anterior vam veure arquitectures event-driven on un procés es reparteix en molts passos independents. Però això crea un problema delicat: què passa si un procés té diversos passos i un d’ells falla a mig fer? Per exemple, en una comanda es cobra el pagament però després falla la reserva d’estoc. Quedaria un client cobrat sense producte: un estat inconsistent. El patró Saga és la solució per coordinar processos de diversos passos que poden fallar, mantenint-ho tot coherent. El vam esmentar breument al subcapítol 15.4; aquí el veiem a fons.

En un sistema d’un sol bloc amb una base de dades, hi ha un mecanisme clàssic per a això: les transaccions. Una transacció diu «o es fan tots els passos, o no se’n fa cap»; si alguna cosa falla a mig fer, tot es desfà automàticament (rollback) i es queda com al principi. És el principi de «tot o res».

Però en una arquitectura de microserveis (Capítol 17) o serverless (Capítol 28), cada pas el fa un servei diferent, amb la seva pròpia base de dades. No hi ha una transacció única que els abasti a tots. Si el pas 3 de 5 falla, els passos 1 i 2 ja s’han executat en altres serveis i no es desfan sols:

Necessites una manera de mantenir la consistència quan una operació es reparteix entre diversos serveis i alguna cosa falla a mig fer. Això és la Saga.

El patró Saga gestiona una operació de diversos passos repartits entre serveis, de manera que, si un pas falla, els passos anteriors es desfan mitjançant accions compensatòries (operacions que cancel·len el que ja s’ha fet). En comptes d’un «rollback automàtic» (que no existeix entre serveis), defineixes com desfer cada pas, i la Saga les executa en ordre invers si alguna cosa falla.

Analogia: una Saga és com reservar unes vacances per parts (vol, hotel i cotxe de lloguer, cadascun en una web diferent). Reserves el vol ✓, reserves l’hotel ✓... i quan vas a llogar el cotxe, no hi ha disponibilitat ✗. Com que no pots anar-hi sense cotxe, has de cancel·lar el que havies fet abans: cancel·les l’hotel (i et tornen els diners) i cancel·les el vol. Cada cancel·lació és una acció compensatòria que desfà una reserva. Al final, estàs com al principi, sense reserves a mitges. La Saga automatitza exactament aquesta lògica de «si alguna cosa falla, desfaig el que havia fet abans pas a pas».

La diferència essencial amb una transacció tradicional: en una Saga no hi ha un rollback automàtic. En el seu lloc, tu defineixes explícitament com desfer cada pas (la seva acció compensatòria), i la Saga les executa quan cal. Això requereix pensar, per a cada pas, «com ho cancel·lo si després alguna cosa falla?».

Per això, en dissenyar una Saga, per a cada acció penses també en la seva acció contrària: cobrar ↔ reemborsar, reservar ↔ alliberar, crear ↔ esborrar.

Hi ha dues formes habituals de coordinar una Saga, connectades amb el que ja saps:

• Per coreografia (amb esdeveniments): cada servei reacciona a esdeveniments (estil event-driven del subcapítol 28.1) i, si alguna cosa falla, emet un esdeveniment de fallada que dispara les compensacions. No hi ha un «director»; els serveis es coordinen entre si per esdeveniments.
• Per orquestració (amb un coordinador): un component central dirigeix els passos i, si un falla, ordena les compensacions. A AWS, l’eina ideal per a això és Step Functions, que veurem al següent subcapítol (28.3): permet definir el flux de passos i què fer si cada un falla, de manera visual i controlada.

• Quan tens un procés de diversos passos repartit entre diversos serveis (microserveis, serverless) i necessites que sigui consistent encara que alguna cosa falli a mig fer.
• Processos de negoci crítics com comandes, pagaments, reserves, on deixar alguna cosa «a mitges» seria un problema greu.

⚠️ Si la teva operació cap en un sol servei amb una base de dades, fes servir una transacció normal (és més simple). La Saga és per quan l’operació travessa diversos serveis i no hi ha transacció comuna possible.

Exemple del món real: una plataforma de viatges processa la reserva d’un paquet complet: vol, hotel i trasllat, cadascun gestionat per un servei diferent (a vegades de proveïdors externs). Implementen una Saga: reserven el vol, després l’hotel, després el trasllat. Si en l’últim pas el trasllat no està disponible, la Saga executa les compensacions: cancel·la l’hotel i cancel·la el vol automàticament, tornant el client a un estat net (sense reserves parcials ni cobraments indeguts). El client rep un «no ha estat possible completar la reserva» en comptes de quedar-se amb un vol i un hotel però sense manera d’arribar-hi. La Saga garanteix que el procés és tot o res, encara que per dins siguin molts serveis independents.

• En microserveis/serverless, una operació de diversos passos es reparteix entre diversos serveis sense una transacció comuna; si un pas falla a mig fer, els anteriors ja s’han executat i quedaria un estat inconsistent.
• El patró Saga gestiona aquests processos de manera que, si un pas falla, els anteriors es desfan mitjançant accions compensatòries (operacions que cancel·len el que ja s’ha fet), tornant a un estat consistent. Com cancel·lar per parts una reserva de vacances si alguna cosa no quadra.
• La clau: no hi ha rollback automàtic com en una base de dades; tu defineixes com desfer cada pas (cobrar↔reemborsar, reservar↔alliberar).
• S’implementa per coreografia (esdeveniments, estil 28.1) o per orquestració (un coordinador com Step Functions, subcap. 28.3).
• Fes-lo servir per a processos crítics de diversos serveis (comandes, pagaments, reserves). ⚠️ Si tot cap en un servei amb una base de dades, fes servir una transacció normal (més simple).

Al següent subcapítol veurem l’eina d’AWS ideal per orquestrar aquests fluxos de diversos passos de manera visual i controlada: Step Functions.