Vendredi dernier, nos techs se sont réunis en ligne, dans le cadre de notre Communauté Tech pour regarder et discuter de la vidéo du talk Lost in transaction de Bernd Ruecker, tenu lors de la conférence DDD Europe en 2019.
Dans ce talk, Bernd explique que dans un monde où les applications sont désormais de plus en plus distribuées, notamment avec l'avènement des architectures microservices, il est important de revoir notre point de vue concernant les transactions.
Parfois, il faut savoir sacrifier la consistence pour privilégier la disponibilité !
En tant que bons développeurs, nous avons tous appris à l'école qu'il était important de garantir, lorsqu'on clique sur le bouton "SAVE" d'une application, que toutes les données soient sauvées d'un bloc et que leur consistance soit garantie. C'est ce que permettent les caractéristiques ACID d'une transaction.
Mais est-ce toujours aussi vrai ?
Certes, la consistance des données est toujours aussi importante. Mais doit-elle réellement être systématiquement garantie au moment où on clique sur le bouton "SAVE" ?
Le point de vue de nombreux leaders du développement applicatif aujourd'hui est qu'on peut retarder le moment où les données seront consistantes (Eventual Consistency), afin de garantir une plus haute disponibilité du système tout en donnant un feedback plus rapide à l'utilisateur.
Pendant qu'un processus métier, qui peut parfois être long, se met en place de façon asynchrone; côté serveur, l'utilisateur est notifié que sa demande a bien été pise en compte puis est libre de continuer ce qu'il a à faire.
Si jamais quelque chose se passe mal, plusieurs stratégies peuvent être misent en œuvre pour remédier au problème et mener des actions de compensation.
Pensez à ce qui se passe lorsque vous passez commande sur Amazon par exemple.
Une fois les informations de paiement et l'adresse de livraison fournies, Amazon vous notifie que votre commande est bien prise en compte et vous invite à continuer votre shopping. A ce moment, tout un processus se met en œuvre pour procéder au paiement, vérifier s'il y a du stock dans les entrepôts, préparer votre commande et procéder à son envoi.
Si vous êtes arrivé à la limite maximum sur votre carte de crédit, Amazon ne vous dit pas qu'ils refusent d'honorer votre commande. Ce ne serait pas dans leur intérêt. Au contraire, ils vous envoie plutôt un email de notification vous demandant de changer de moyen de paiement. De la même manière, si un produit que vous avez n'est plus en stock, Amazon vous envoie un email et vous laisse le choix soit d'être remboursé pour le produit manquant, soit d'attendre.
Pourquoi Amazon a choisi ce modèle ?
Parce que cela leur permet d'une part d'avoir des systèmes hautement disponibles et résilients, certes, mais aussi parce que d'autre part ça leur apporte un avantage compétitif. Ils ont tout intérêt à ce que le client passe plus de temps à faire du shopping qu'à attendre que la transaction bancaire en ligne ait été effectuée. De la même manière, ils ont privilégié le fait d'accepter la commande au risque de ne plus avoir le produit en stock, plutôt que de valider et bloquer le stock lors de la commande.
Amazon a su tirer partie d'une contrainte technique pour en faire un avantage. En tenant compte du fait qu'une transaction ACID aurait rendu leur système lent et difficile à faire monter en charge, Amazon a finit par offrir a ses clients une meilleure expérience utilisateur.
Dans son talk, Bernd ne cite pas explicitement cet exemple, mais c'est bien de cela dont il s'agit.
Il est parfois nécessaire de sacrifier la consistance des données, même temporairement, afin de privilégier la disponibilité du système. Cela implique qu'il faut orchestrer ces transactions longues et mettre en place des actions de compensations quand nécessaire.
Construire ce genre de système n'est pas chose facile. Chez Agile Partner, nous pouvons vous y aider.
Si vous souhaitez répondre à ce type de préoccupations auxquelles vos équipes techniques sont confrontées et souhaitez des conseils, nous vous aidons rapidement et à distance grâce à notre offre One Time Tech Partner. Alors réservez votre session dès maintenant !
Ressources supplémentaires:
https://github.com/berndruecker/
Vous avez un projet de développement logiciel ? Vous avez besoin d'aide pour améliorer votre agilité ?
L’article Sacrifier la consistance pour privilégier la disponibilité est apparu en premier sur AgilePartner.
