En un monòlit amb una sola base de dades, mantenir la coherència és senzill: ho emboliques tot en una transacció ACID i, si alguna cosa falla, fas ROLLBACK i és com si no hagués passat res. Però en una arquitectura de microserveis cada servei té la seva pròpia base de dades, i una operació de negoci (com "tramitar una comanda") abasta diversos d'ells. No existeix un ROLLBACK global que abasti bases de dades diferents i serveis remots. Com garantim, doncs, la coherència d'una operació que toca comandes, pagaments, inventari i enviaments?

La resposta és el patró Saga: dividim la transacció distribuïda en una seqüència de transaccions locals, cadascuna en un servei, coordinades mitjançant esdeveniments o missatges. Si un pas falla, en lloc d'un rollback executem transaccions de compensació que desfan semànticament els passos anteriors. En aquesta lliçó estudiarem les dues formes d'implementar sagues (coreografia i orquestració), el concepte de compensació i un exemple complet de comanda.

1. El problema de les transaccions distribuïdes
2. Què és una Saga i les transaccions de compensació
3. Saga per coreografia
4. Saga per orquestració
5. Comparativa coreografia vs orquestració
6. Exemple complet: tramitar una comanda (amb diagrama)
7. Errors comuns i consells
8. Exercicis i solucions
9. Conclusió

Imagina el flux "tramitar comanda":

1. Comandes crea la comanda.
2. Pagaments cobra al client.
3. Inventari reserva l'estoc.
4. Enviaments programa el repartiment.

Si el pas 3 falla (no hi ha estoc), el cobrament del pas 2 ja s'ha realitzat. No podem fer un ROLLBACK distribuït perquè:

• Cada servei té la seva pròpia BD; no comparteixen transacció.
• Les solucions clàssiques com el Two-Phase Commit (2PC) bloquegen recursos, escalen malament i creen un fort acoblament. A la pràctica gairebé ningú no les fa servir en microserveis.

La saga accepta una veritat incòmoda: en sistemes distribuïts busquem consistència eventual, no consistència immediata. Hi haurà un instant en què el cobrament està fet però l'estoc no reservat; la saga garanteix que el sistema acabi en un estat coherent (tot confirmat o tot compensat).

Una saga és una seqüència de transaccions locals T1, T2, ..., Tn. Cada Ti té una transacció de compensació Ci que desfà el seu efecte. Si T1, T2, T3 tenen èxit però T4 falla, la saga executa C3, C2, C1 en ordre invers.

Aspectes crucials de les compensacions:

• No és un rollback tècnic, sinó semàntic. No "esborres" el cobrament; emets un reemborsament. L'historial queda (important per a l'auditoria).
• Han de ser idempotents i no poder fallar (o tenir reintents robustos), perquè si la compensació falla, el sistema queda inconsistent.
• Algunes accions no es poden compensar (enviar un email ja enviat). Per a aquestes, es reordena la saga per executar-les al final, quan ja no hi ha marxa enrere (pivot transaction).

En la coreografia no hi ha coordinador central. Cada servei escolta esdeveniments, fa la seva feina i emet un nou esdeveniment que dispara el següent. El flux "emergeix" de les reaccions encadenades (és la topologia de broker de la lliçó 05-01).

• Camí feliç (línies contínues): cada esdeveniment dispara el servei següent.
• Camí de fallada (línies puntejades): si Inventari emet StockAgotat, Pagaments reacciona reemborsant i Comandes cancel·la. Les compensacions també viatgen com a esdeveniments.

Avantatges: màxim desacoblament, sense punt únic de fallada. Inconvenients: el flux global no és enlloc; amb molts passos es torna difícil de seguir i depurar (risc de "dependències cícliques" d'esdeveniments).

En l'orquestració, un component central —l'orquestrador— dirigeix la saga: envia comandes a cada servei, espera la resposta i decideix el pas següent o llança les compensacions (és la topologia de mediador).

Explicació detallada:

• L'orquestrador coneix tot el flux: l'ordre dels passos i les seves compensacions. Això centralitza la lògica del procés en un únic lloc llegible.
• EstadoSaga registra quins passos s'han completat. És essencial persistir-lo (en BD), perquè si l'orquestrador es reinicia a mitges ha de saber per on anava per reprendre o compensar.
• A compensar, només desfem els passos que sí que es van executar, en ordre invers: primer alliberar estoc, després reemborsar, després cancel·lar la comanda.
• En producció, les crides solen ser asíncrones (comandes per cua i respostes per esdeveniments) en lloc d'invocacions bloquejants, però la lògica de coordinació és la mateixa.

Regla pràctica: fes servir coreografia per a sagues curtes i simples; fes servir orquestració quan el procés tingui molts passos, lògica condicional o necessitis visibilitat i control clars.

Diagrama de seqüència de la saga orquestrada, incloent el camí de compensació quan falta estoc:

Observa que no hi ha reserva d'estoc per alliberar (aquest pas va fallar), per la qual cosa la compensació arrenca directament en el reemborsament del pagament i acaba cancel·lant la comanda. El sistema queda en un estat coherent: el client no ha pagat i no té comanda.

Un detall clau d'implementació: cada compensació ha de ser idempotent. Si l'orquestrador reintenta reemborsar(comanda) perquè no va rebre resposta, el servei de Pagaments ha de fer servir la clau d'idempotència (lliçó 05-02) per no reemborsar dues vegades.

• Compensacions que poden fallar i no es reintenten. Si una compensació falla i no hi ha reintents, el sistema queda inconsistent sense remei. Fes-les idempotents i amb reintents persistents.
• No persistir l'estat de la saga. Si l'orquestrador es reinicia i no sap quins passos va fer, no pot compensar correctament. L'estat de la saga ha de sobreviure a caigudes.
• Intentar compensar accions irreversibles. Un email enviat no es "des-envia". Col·loca aquestes accions al final de la saga (després de la pivot transaction) o emet una acció correctora (un email de disculpa).
• Confondre saga amb 2PC. La saga no ofereix aïllament: durant la seva execució, altres poden veure estats intermedis. Cal dissenyar comptant amb això (estats "PENDENT", reserves temporals, etc.).
• Consell: modela explícitament cada estat intermedi de la comanda (PENDENT_PAGAMENT, PAGAT, CANCEL·LAT) perquè la inconsistència temporal sigui visible i controlada, no accidental.

1. Defineix les transaccions de compensació per a aquesta saga de reserva de viatge: T1 reservar vol, T2 reservar hotel, T3 llogar cotxe. Si T3 falla, quines compensacions s'executen i en quin ordre?
2. Per al flux "alta de pòlissa d'assegurança" (validar dades, tarificar, cobrar prima, emetre pòlissa, enviar email de benvinguda) decideix si faries servir coreografia o orquestració i on col·locaries l'enviament de l'email. Justifica-ho.
3. Explica per què les transaccions de compensació han de ser idempotents, fent servir com a exemple un reemborsament de pagament en una saga amb reintents.

1. Compensacions: C1 cancel·lar vol, C2 cancel·lar hotel, C3 cancel·lar cotxe. Si T3 falla, no hi ha cotxe per cancel·lar; es compensen els passos previs en ordre invers: primer C2 (cancel·lar hotel) i després C1 (cancel·lar vol).
2. Orquestració, perquè és un flux llarg amb diversos passos i lògica condicional (la tarificació i el cobrament poden rebutjar), i es necessita visibilitat/control per a un procés regulat. L'email de benvinguda va al final, com a acció no compensable després de la pivot transaction (emetre pòlissa): només s'envia quan ja no hi ha marxa enrere, evitant haver de "des-enviar" un correu si alguna cosa falla abans.
3. Amb reintents (at-least-once), l'orquestrador pot invocar reemborsar(comanda) més d'una vegada si no rep confirmació. Si la compensació no fos idempotent, reemborsaríem al client dues o més vegades. Fent servir la clau d'idempotència del pagament, el servei detecta que aquest reemborsament ja es va fer i l'ignora, garantint un únic reemborsament malgrat els reintents.

El patró Saga resol el problema de les transaccions distribuïdes descomponent-les en transaccions locals coordinades, amb compensacions semàntiques que desfan la feina quan un pas falla. Vam distingir la coreografia (esdeveniments encadenats, màxim desacoblament) de l'orquestració (coordinador central, màxima visibilitat), i vam veure que la idempotència de les compensacions és innegociable. A més, vam assumir que guanyem coherència eventual a canvi de tolerar estats intermedis.

En la lliçó següent, "Streaming de Dades en Temps Real", tanquem el mòdul veient com processar fluxos continus d'esdeveniments —ja no operacions individuals— per a analítica i reacció en temps real amb eines com Kafka Streams.