Un saga gère une transaction métier qui s'étend sur plusieurs services comme une séquence de transactions locales. Si une étape échoue, le saga exécute des transactions de compensation pour annuler les étapes précédentes — il n'y a pas de rollback distribué.
Le commit à deux phases entre services est lent, verrouille les ressources et crée un couplage. Les sagas offrent une cohérence éventuelle sans verrous distribués.
Les services réagissent aux événements les uns des autres ; pas de coordinateur central.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
Un orchestrateur indique à chaque service ce qu'il doit faire et réagit aux résultats.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
| Aspect | Chorégraphie | Orchestration |
|---|---|---|
| Coordination | Distribuée (événements) | Centralisée |
| Couplage | Plus faible | Orchestrateur connaît le flux |
| Visibilité | Difficile à suivre | Facile à tracer |
| Optimal pour | Étapes simples, peu nombreuses | Complexe, nombreuses étapes |
Les compensations doivent être idempotentes et gérer le cas où l'étape initiale a partiellement réussi. Concevez-les avec soin.
Les sagas sont la façon de maintenir la cohérence des données entre services sans le coût et le couplage des transactions distribuées.
Choisir entre la chorégraphie et l'orchestration revient à échanger la simplicité pour la visibilité : les événements se mettent à l'échelle de manière souple mais deviennent complexes, tandis qu'un orchestrateur centralise la logique complexe au prix d'un composant supplémentaire à exécuter.