Après une coupure : réconcilier les données et compenser les actions

La connexion revient, mais la commande apparaît payée sur un écran et en attente sur un autre. Remettre les données à jour réglera cet affichage. Si deux paiements ont réellement eu lieu, il faudra aussi rembourser le débit en trop. La reprise demande donc d'identifier ce qui peut être recalculé et ce qui nécessite une nouvelle action métier.

Commencer par identifier ce qui a changé

Après une coupure de communication, plusieurs situations peuvent coexister. Une copie n'a pas reçu les dernières mises à jour. Deux parties ont accepté des modifications incompatibles. Un prestataire a exécuté une action sans que sa confirmation soit arrivée. Il faut établir ce qui s'est réellement produit avant de relancer les traitements.

Dans cet article, la réconciliation désigne le rapprochement des données ; la compensation désigne une nouvelle action qui corrige un effet déjà réalisé. Les termes peuvent se recouvrir dans d'autres descriptions. La distinction aide surtout à éviter de confondre une correction d'affichage avec un remboursement.

Retrouver un état de référence pour les copies

Pour une copie calculée à partir d'une source, le traitement peut relire cette source et reconstruire la copie. Il faut donc savoir quelles données font référence. Si plusieurs parties ont accepté des écritures indépendantes, une règle de résolution des conflits est également nécessaire.

Le rattrapage prend ensuite des formes connues :

• le replay, qui rejoue les événements enregistrés pour reconstruire l'état dérivé ;
• le recalcul de projection, qui régénère une vue ou un index depuis la source ;
• la resynchronisation, qui réaligne une copie sur l'état de référence ;
• la détection d'écart suivie d'une réparation ciblée, quand seule une partie a divergé.

Ces méthodes fonctionnent si les informations nécessaires ont été conservées. Une vue ou un index peut être reconstruit depuis sa source ; une donnée unique ajoutée uniquement dans cette vue ne le peut pas. Je recommande de vérifier la reconstruction avant de considérer une copie comme remplaçable.

Les CRDT prévoient les règles de fusion des copies

Les CRDT sont des structures de données conçues pour que des copies modifiées séparément puissent converger selon des règles définies à l'avance (Shapiro et ses coauteurs, 2011). Les mises à jour doivent encore circuler ; les règles de la structure déterminent comment elles sont combinées.

Pour les CRDT qui échangent des états, la fusion doit donner le même résultat quel que soit l'ordre des états reçus ou leur regroupement. Recevoir deux fois le même état ne doit rien ajouter : c'est l'idempotence. Ces propriétés sont appelées commutativité, associativité et idempotence.

Les CRDT qui échangent des opérations reposent sur d'autres conditions de livraison et sur des opérations concurrentes compatibles entre elles. Le choix de la structure et celui du transport doivent donc être étudiés ensemble.

Un compteur ou un ensemble s'y prêtent. Une opération qui exige un arbitrage, non. Le détail de ces structures mérite son propre article.

Préciser le retard acceptable et le moyen de le corriger

La cohérence à terme, ou eventual consistency, signifie que les copies finiront par se rejoindre si aucune nouvelle modification n'intervient et si les mises à jour nécessaires sont finalement propagées. Elle ne donne pas, à elle seule, de durée maximale pour ce rattrapage.

Pour rendre cette garantie utile, précisez la source ou la règle de fusion, le délai de propagation acceptable et les lectures qui peuvent utiliser des données anciennes. Ajoutez les mesures qui détectent un retard et le traitement qui le corrige. Une promesse de convergence a besoin d'un mécanisme de reprise qui fonctionne.

Corriger une action déjà effectuée

Une compensation ajoute une action qui corrige les conséquences d'une précédente. Un remboursement répond à un paiement. La libération d'une place répond à une réservation annulée. Un courriel envoyé ne peut pas être rappelé avec certitude ; il faudra parfois envoyer une rectification.

Dans une transaction locale non validée, un rollback abandonne les modifications. Après validation, ou lorsqu'un prestataire externe a déjà agi, ce retour arrière n'est généralement plus disponible. L'application doit alors utiliser une opération métier adaptée à ce qui s'est passé.

La compensation pose donc une action correcte : annuler une réservation, émettre un avoir plutôt que prétendre n'avoir jamais facturé, rouvrir une capacité consommée, ou prévenir un opérateur pour reprise. L'avoir n'efface pas la facture, il lui répond, et les deux restent dans l'historique.

La trace doit relier l'action initiale et sa correction. Un opérateur pourra ainsi retrouver pourquoi un remboursement a été demandé, s'il a abouti et ce qui reste à traiter.

Comment une saga organise les compensations

Une saga organise une suite d'étapes qui valident chacune leur travail, avec des compensations prévues si la suite échoue. Garcia-Molina et Salem ont décrit cette approche en 1987 pour les transactions longues. Elle est aussi utilisée pour des parcours répartis entre plusieurs services.

Le terme de transaction de compensation, lui, est plus ancien encore : Jim Gray l'emploie en 1981, et les auteurs des sagas le citent à ce titre.

Pour chaque étape, définissez le résultat attendu, les erreurs possibles et le moyen de reprendre ou de compenser. Dans une orchestration, un composant pilote la suite. Dans une chorégraphie, les composants réagissent aux événements. Dans les deux cas, quelqu'un doit pouvoir retrouver l'état global du parcours.

Si l'expédition échoue après la prise du paiement, la saga ne tente aucun retour arrière global. Elle déclenche le remboursement et la libération de la place.

Le remboursement peut échouer à son tour, si la passerelle de paiement est injoignable. Concevez donc chaque compensation rejouable et idempotente, avec une reprise manuelle en dernier recours.

Une compensation peut échouer ou être impossible. Le remboursement lui-même peut nécessiter une reprise si le prestataire ne répond pas. Pour une action irréversible, le parcours doit prévoir les vérifications ou les validations nécessaires avant de l'engager ; une saga ne rend pas tous les effets annulables.

Sources

• H. Garcia-Molina & K. Salem, Sagas, SIGMOD, 1987.
• J. Gray, The Transaction Concept: Virtues and Limitations, VLDB, 1981.
• C. Richardson, Pattern: Saga, microservices.io.
• M. Shapiro, N. Preguiça, C. Baquero et M. Zawirski, Conflict-free Replicated Data Types, SSS 2011.
• E. Brewer, CAP Twelve Years Later, 2012.