Bonjour, Habr! Je vous présente la traduction de l'article "Pattern: Saga" de Chris Richardson.
La situation
Il existe une application à laquelle le modèle de base de données par service a été appliqué. Désormais, chaque service d'application a sa propre base de données. Certaines transactions commerciales couvrent plusieurs services à la fois, un mécanisme est donc nécessaire pour garantir la cohérence des données entre ces services.
Par exemple: imaginons que nous développons une boutique en ligne où un client a une limite de crédit. L'application doit s'assurer que la nouvelle commande ne dépasse pas la limite de crédit du client. Étant donné que les commandes et les clients sont des bases de données différentes, l'application ne peut pas utiliser les transactions ACID locales.
Le problème
Comment assurer la cohérence des données entre les services?
Solution
Chaque transaction commerciale qui couvre plusieurs services doit être implémentée comme une saga.
Une saga est un ensemble de transactions locales. Chaque transaction locale met à jour la base de données et publie un message ou un événement, initiant la prochaine transaction locale dans la saga. Si la transaction a échoué, par exemple, en raison d'une violation des règles commerciales, la saga lance des transactions compensatoires qui annulent les modifications apportées par les transactions locales précédentes.

Il existe deux façons de coordonner les sagas:
- Chorégraphie - Chaque transaction publie des événements qui déclenchent des transactions dans d'autres services.
- Orchestration - Un orchestrateur indique aux participants quelles transactions doivent être démarrées.
Exemple: Saga basée sur la chorégraphie

Dans une boutique en ligne utilisant une saga basée sur la chorégraphie, la création d'une commande comprendra les étapes suivantes:
Order Service ( )
crée une Order ()
dans l'état en attente (en attente) et publie l'événement OrderCreated ()
Customer Service ( )
reçoit un événement et essaie de réserver le crédit de la commande. Ensuite, il publie l'un des deux événements: CreditReserved ()
ou CreditLimitExceeded ()
Order Service ( )
reçoit un événement et change le statut de la commande en approuvé (confirmé) ou annulé (annulé)
Exemple: Saga orchestrale

Dans une boutique en ligne utilisant une saga basée sur l'orchestration, la création d'une commande comprendra les étapes suivantes:
Order Service ( )
crée une Order ()
dans l'état en attente (en attente) et crée une CreateOrderSaga ()
CreateOrderSaga ()
envoie la commande ReserveCredit ()
au Customer Service ( )
Customer Service ( )
essaie de réserver un prêt pour une commande et renvoie une réponseCreateOrderSaga ()
reçoit une réponse et envoie une commande ApproveOrder ()
ou RejectOrder ()
dans le Order Service ( )
Order Service ( )
change le statut de la commande en approuvé (confirmé) ou annulé (annulé)
Saga présente les avantages suivants
- Permet à une application de maintenir la cohérence des données entre les services sans utiliser de transactions distribuées.
La saga présente les inconvénients suivants
- Le modèle de programmation devient de plus en plus complexe. Par exemple, les développeurs doivent concevoir des transactions compensatoires qui annulent les modifications apportées plus tôt dans la saga.