Sagas : coordonner plusieurs opérations et gérer leurs échecs

Le vol est réservé, mais l'hôtel est complet. Le système doit alors trouver une autre solution ou annuler la réservation du vol. Une saga organise ce type de parcours lorsque les participants ne partagent pas une transaction commune. Elle décrit les étapes à réaliser et la conduite à tenir si l'une échoue.

Une suite de décisions locales

Dans une saga, chaque étape valide son propre changement. Le service des vols réserve une place ; celui des hôtels réserve une chambre ; le paiement suit selon les règles du parcours.

Il n'existe pas de validation unique qui rende instantanément l'ensemble définitif. Entre deux étapes, le voyage est dans un état intermédiaire, par exemple « vol réservé, hôtel en attente ».

Le mécanisme a été décrit par Hector Garcia-Molina et Kenneth Salem en 1987 pour découper des transactions longues. Son utilisation entre services autonomes est une application courante de cette idée.

Vérifier d'abord si cette complexité est nécessaire

Si toutes les données peuvent être modifiées dans une transaction locale courte, cette solution peut être plus simple. Une saga devient pertinente lorsque le parcours traverse plusieurs systèmes, dure longtemps ou dépend d'acteurs qui ne participent pas à la même transaction.

Les transactions distribuées existent, mais tous les services ne les prennent pas en charge. Elles ajoutent des contraintes de coordination et de disponibilité. Leur coût doit être évalué dans le contexte réel ; il n'est pas utile de les déclarer impossibles dans tous les cas.

Choisir où décrire l'enchaînement

En chorégraphie, chaque participant réagit aux événements des autres. L'annonce « vol réservé » déclenche, par exemple, la recherche d'une chambre.

En orchestration, un coordinateur suit l'avancement et demande les étapes suivantes. Il peut savoir qu'il attend une réponse de l'hôtel avant de poursuivre.

Je privilégie l'orchestration lorsque le parcours comporte de nombreuses branches, des délais ou des interventions humaines. Pour quelques réactions indépendantes, la chorégraphie peut suffire.

Une compensation est une nouvelle action métier

Si l'hôtel est complet, la réservation du vol a déjà eu lieu. On ne peut pas annuler une transaction globale qui n'existait pas. On demande au service des vols une nouvelle opération : annuler cette réservation.

C'est une compensation. Elle contrebalance un effet précédent sans effacer son existence. L'historique peut donc montrer « réservé », puis « annulé ». Un remboursement suit le même principe : le paiement initial reste un fait.

Tous les effets ne sont pas entièrement compensables. Une réservation non remboursable peut laisser des frais ; un courriel envoyé ne peut pas être retiré de la boîte du destinataire. Le métier doit définir le résultat acceptable et les cas qui exigent une intervention.

Distinguer un refus d'une réponse perdue

Un hôtel qui répond « complet » a refusé la réservation. Un appel qui expire ne permet pas de conclure : la réservation peut avoir réussi sans que sa réponse soit arrivée.

Dans ce second cas, il faut rechercher l'opération ou la reprendre avec un identifiant stable. Relancer une réservation avec un nouvel identifiant risquerait de créer un doublon. L'idempotence aide à rendre ces reprises sûres.

Les compensations peuvent elles aussi échouer temporairement. Elles doivent être suivies et reprises. Le statut « annulation en cours » est plus exact qu'une réussite annoncée avant d'avoir reçu la confirmation.

Conserver l'avancement et rendre les attentes visibles

Un coordinateur peut stocker son état : étapes terminées, demandes envoyées, réponses attendues et compensations engagées. Ce suivi durable lui permet de reprendre après une interruption.

Il ne remplace pas les données de référence de chaque participant. Un statut de voyage doit refléter les confirmations effectivement reçues, sans promettre un « tout ou rien » que le système ne garantit pas.

Les opérations concurrentes demandent aussi des règles : réservation temporaire d'une place, date d'expiration ou restriction de certaines modifications pendant le parcours. Une saga ne fournit pas automatiquement l'isolation d'une transaction unique.

Préparer les sorties possibles avant de coder

Pour chaque étape, indiquez son effet, la manière de reconnaître sa réussite, les erreurs à reprendre et sa compensation éventuelle. Ajoutez une durée maximale et le traitement des situations qui restent indécises.

La réconciliation complète ce dispositif en rapprochant les états observés et les résultats attendus. Elle ne se confond pas avec une compensation, qui produit une nouvelle décision métier.

CQRS répond à une autre question, celle de la séparation entre commandes et lectures. Une saga peut être utile avec ou sans CQRS ; elle se choisit parce qu'un parcours doit coordonner plusieurs décisions.

Sources

• J. Gray, The Transaction Concept: Virtues and Limitations, VLDB, 1981.
• H. Garcia-Molina et K. Salem, Sagas, ACM SIGMOD, 1987.
• C. Richardson, Pattern: Saga.
• V. Vernon, Effective Aggregate Design, partie I, 2011.
• V. Vernon, Effective Aggregate Design, partie II, 2011.