Transactions distribuées et Sagas
Progression
#Transactions distribuées et Sagas
La cohérence stricte d’une transaction ACID sur plusieurs services exige de la coordination. Le protocole en deux phases (2PC) vote puis engage, mais il bloque si le coordinateur tombe au mauvais moment. En présence de partitions réseau, ce blocage devient fréquent, et la disponibilité se dégrade.
Les Sagas prennent une autre voie: elles décomposent une transaction globale en une suite d’étapes locales, chacune avec une action compensatrice. Si une étape échoue, on exécute les compensations pour annuler les effets déjà appliqués. La responsabilité métier se déplace des invariants « atomiques » vers des invariants « finalement vrais », ce qui simplifie la disponibilité mais demande d’anticiper les cas intermédiaires.
Le choix entre 2PC, journaux répliqués et Sagas dépend de la criticité de l’invariant, de la tolérance au retard et du coût accepté de coordination. Une solution pragmatique réserve la coordination forte aux rares mises à jour qui l’exigent, et utilise Sagas pour le reste.
#Diagramme: Saga orchestrée (avec compensations)
Mini‑exercice: pour une commande e‑commerce (réserver stock, débiter paiement, créer livraison), proposez actions/compensations et quelles erreurs doivent déclencher un retry vs un abandon.