L'addiction des développeurs aux transactions, ou leur refus de gérer l'éventual consistency.

Vidéo suggérée en amont de la session :

“Six little line of fail” - Jimmy Bogard

Déroulement

Petite présentation de la problématique : l’eventual consistency est partout dans la vie réel, mais côté logiciel on peine à l’accepter ou le modéliser.
Une conséquence est l’usage (intensif) de transactions qui permettent de faire des transitions entre 2 états sans inconsistance. Mais celà apporte des contraintes/limitations en terme de découplage dans le code et de performances.
À l’opposé, l’eventual consistency peut avoir de forts impacts sur le métier et doivent faire l’objet de stratégies dédiées.

Séparation du groupe en deux salles en fonction des niveaux de chacun.

Groupe 1 : “BA ba”

Les isolations des transactions en base de données

Théorme du CAP two-phase commit

Côté front, il faut gérer correctement l’aspect asynchrone en attrapant les erreurs (désactivation des boutons pendant le traitement, etc.).
Côté back, bien retourner des réponses adaptées (succès, échec avec la raison)

Utilisation d’identifiant de corrélation pour suivre les conséquences d’une action.

Lorsqu’une requête/processus échoue : c’est au métier que revient la décision de comment le gérer, car c’est le métier qui sera impacté

Groupe 2 : “Pour aller plus loin”

La transaction a un aspect pratique car elle évite de représenter les état inconsistants, mais on ne veut pas inclure des bounded context différents.
Une agrégat = une transaction -> relève du dogme.

Risque plus élevé / évident avec des appels à des services externes, exemple avec un appel REST sans réponse :
- le service a-t-il reçu ma demande ?
- le service a-t-il réussi ?
- le service a-t-il échoué ?
- le service a-t-il répondu (et je n’ai pas reçu sa réponse) ?
Une API idempotent est plus sûre de ce point de vue, elle autorise les retry.

Les SAGA/process manager permettent de modéliser la durée la vie et le déroulé d’un process.

Anticiper tous les cas d’erreur peut être très complexe, automatiser la compensation des cas d’erreur peut s’avérer complexe, coûteux et ajoute encore plus de complexité et d’erreur. Une solution simple peut-être de notifier un opérateur humain (log, mail) qui lui interviendra pour résoudre le problème. L’automatisation devient intéressante quand le nombre d’occurrences, la fréquence ou la répartition dans le temps de l’erreur le justifie.

Conséquence d’une référence vs une duplication de données, exemple entre une désynchro entre un front-end (data-version 1) et un back-end (data version 2) :

  • référence : je lie une entité à la version 2 en pensant lier à la version 1
  • copie : j’enregistre une version 1 dans l’entité alors que la version actuelle dans le référentiel est la version 2
    -> ces choix ont des conséquences métier et doivent être considérés d’un point de vue métier avant d’être technique.

Heuristique proposé par Florent : Création - Flux - Analyse

  • Brouillon/Création : saisie libre sans réelle contraintes sur la data
  • Run/Flux : contraintes sur la data, saisies guidé par un flux
  • Analyse : data figée qui ne doit plus évoluer
    -> Différents concepts / différentes tables en BDD

“All your aggregates are wrong” - Mauro Servienti

Identifier les périmètres de data et la fréquence à laquelle ces données sont mis à jour: frontières naturelles pour des agrégats.
Une forme de compensation pour rattraper une inconsistance : recalculer une projection (à intervalle régulier).

Plusieurs stratégies pour gérer des échecs dans des systèmes avec eventual consistency :

Outbox pattern :
- https://www.kamilgrzybek.com/design/the-outbox-pattern/
- https://microservices.io/patterns/data/transactional-outbox.html
- https://docs.particular.net/nservicebus/outbox/

Retours

Les gens plutôt contents du format (même Gautier), même si certains espéraient voir du code.
Du code proposé par Florent: Mixter Beaucoup d’input, certains s’inquétaient que ce soit dur pour Colin passer autant d’informations.
4 nouvelles personnes.

ROTI

  • 2/5 : 1
  • 3/5 : 6
  • 4/5 : 8
ddd