Saga : transactions sans 2PC

Prérequis : cours 3.2 (agrégats) et 5.3 ; index et transactions.

Pourquoi

Une transaction ACID multi-services n'existe pas (le 2PC — commit en 2 phases — est fragile et verrouille tout : à éviter). La saga orchestre des transactions locales + compensations : la voie réaliste du distribué.

Concepts

• Saga : séquence d'étapes locales, chacune avec son action compensatrice (l'annulation métier : rembourser, restocker, annuler l'envoi — pas un ROLLBACK technique).
• Chorégraphie (événements : chaque service réagit et émet la suite) vs orchestration (un chef d'orchestre pilote les étapes). Chorégraphie = simple au début, illisible à 10 services ; orchestration = état central, plus de code.
• Échecs partiels : la norme, pas l'exception. Chaque étape définit : retry ? compensation ? intervention humaine ? « Que se passe-t-il si ça plante ICI » se demande pour chaque flèche du schéma.

Exemple : commande en 3 étapes

1. Paiement débité → compensation : remboursement
2. Stock réservé → compensation : restockage
3. Expédition créée → compensation : annulation transporteur
Échec en 2 : compense 1. Échec en 3 : compense 2 puis 1 (ordre inverse !).

Cas réel

Commande « payée mais jamais expédiée » : paiement OK, réservation stock KO, aucune compensation → argent encaissé, client furieux, régularisation manuelle pendant 3 semaines. Avec saga : remboursement auto en 2 minutes.

Pièges

• Compensation impossible (mail déjà envoyé, colis parti) : prévoir le rattrapage humain (avoir, excuse) — tout ne s'annule pas par code.
• Ordre des compensations : inverse des actions, toujours. Dans l'ordre = incohérences.
• Saga sans observabilité : état de chaque instance visible (dashboard) sinon debug aveugle.

À retenir

Transactions locales + compensations métier ; chorégraphie puis orchestration ; échec partiel = cas nominal.