Les sagas : des workflows multi-étapes entre services, avec compensation au lieu d'un rollback

Ce que c'est

La page de pattern de microservices.io (citée) définit une saga comme une séquence de transactions locales : chacune met à jour la base de données d'un service et publie un message ou un événement qui déclenche la transaction locale suivante. Si une transaction locale échoue parce qu'elle viole une règle métier, la saga exécute des transactions de compensation qui défont les changements effectués par les étapes précédentes. La coordination se fait soit par chorégraphie (chaque service réagit aux événements), soit par orchestration (un orchestrateur indique aux participants quoi faire). La page liste les inconvénients : pas de rollback automatique, puisque les compensations sont écrites à la main, et pas d'isolation, si bien que des sagas concurrentes peuvent lire l'état intermédiaire les unes des autres.

L'Azure Architecture Center (cité) ajoute un vocabulaire utile : une transaction compensable peut être défaite ; une transaction pivot est le point de non-retour, après lequel la saga doit être menée à son terme ; les transactions rejouables (retryable) suivent le pivot et sont idempotentes, de sorte que la saga puisse toujours aboutir.

Pourquoi c'est important

Dès que les données résident dans plusieurs services, « créer la commande, réserver le stock, débiter la carte » ne peut pas être une seule transaction de base de données. Sans saga explicite, les chemins d'échec restent implicites : un débit sans commande, un stock réservé indéfiniment.

Comment l'appliquer

• Écrire le chemin nominal comme une liste d'étapes et, à côté de chaque étape compensable, sa compensation. Si une étape n'a pas de compensation significative (un e-mail envoyé, un paiement capturé), elle constitue le pivot, ou doit venir après lui.
• Ordonner les étapes de sorte que celles les plus susceptibles d'échouer sur des règles métier viennent en premier, et que l'étape irréversible vienne en dernier.
• Rendre chaque étape et chaque compensation idempotente et indexée par l'identifiant de la saga, car les messages sont livrés au moins une fois.
• Persister l'état de la saga (quelle étape a réussi) pour qu'un orchestrateur redémarré reprenne là où il en était plutôt que de tout recommencer ; publier les événements déclencheurs via un outbox.
• Traiter délibérément l'absence d'isolation : marquer les enregistrements comme « en attente » jusqu'à ce que la saga se termine, et faire en sorte que les lecteurs traitent cet état en attente en conséquence.
• Fixer un délai d'expiration par étape et définir ce qui se passe à l'expiration (compenser ou escalader vers un humain).

Pièges

Une compensation est une nouvelle action métier, pas un rollback : rembourser n'est pas « dé-débiter », et cette opération peut elle-même échouer et nécessiter une nouvelle tentative. La page Azure décrit la chorégraphie comme adaptée aux workflows simples comportant peu de services, et note que le flux devient confus à mesure que des étapes s'ajoutent ; un orchestrateur doté d'une machine à états visible est plus facile à exploiter pour des sagas plus longues. Les sagas ne dispensent pas de rendre la dernière étape idempotente face aux nouvelles tentatives.