Dans le palmarès des trucs difficiles à coder, je placerais volontiers dans le peloton de tête les applications collaboratives.
Collaboratif ?
Oui, ça sonne un peu old school. On pense à Lotus Notes qui a connu ses heures de gloires il y a une 15aines d'années.
Un logiciel collaboratif, c'est par exemple un agenda partagé. Un système de covoiturage. Il permet à plusieurs personnes de modifier simultanément une même structure de données.
Avec la suprématie des SaaS et du cloud, on pense que c'est fréquent.
Pas tant que ça en fait.
J'observe que beaucoup d'outils en ligne ne sont pas collaboratifs, car ils gèrent des données rattachées à 1 seul utilisateur : mon billet d'avion, ma to-do liste. On fait fréquemment le pari que 2 utilisateurs ne vont pas se connecter simultanément avec le même login/mot de passe, pour s'éviter des questions compliquées.
En effet, la concurrence d'accès est un problème compliqué. Et qui le devient encore davantage avec cette tendance à vouloir tout distribuer sur plusieurs machines.
Un logiciel collaboratif, c'est un cocktail de problèmes à retardement : tout fonctionne bien en test (avec 1 seul utilisateur), puis les bugs aléatoires éclosent lors de la mise en production : perte de données, incohérences.
Et c'est ainsi que l'on se retrouve avec 12 passagers pour un covoiturage dans une Clio.
L'exemple du covoiturage
Imaginez une webapp pour gérer des covoiturages.
Un conducteur publie un trajet qu'il va réaliser bientôt, et propose d'emmener des passagers pour partager les frais.
Tout le monde peut consulter son annonce, et procéder à une réservation pour ce trajet dans la limite des places disponibles. Pour compliquer, on imagine qu'un passager doté d'un profil "premium" dispose d'un accès prioritaire à la place à l'avant (celui qui choisit la musique...).
Et bien ce covoiturage est un bel exemple d'objet collaboratif : tout le monde le lit en même temps, et tente d'y appliquer des modifications (réserver une place, changer l'horaire, ...).
Le covoiturage est bombardé de demandes simultanées émanant de plusieurs utilisateurs .
Comment réguler cette pagaille ?
Lorsqu'il ne reste qu'une place disponible, comment assurer que 2 demandes de réservations simultanées ne vont pas être acceptées ? Laquelle va-t-on refuser ?
On devine qu'il faut un mécanisme de verrouillage, qui assure que personne d'autre ne modifie le covoiturage alors qu'on est en train d'ajouter une réservation.
Restons optimistes
Il y a 2 façons de s'y prendre : la pessimiste et l'optimiste.
La pessimiste, c'est d'interdire toute lecture ou modification tant que l'on n'a pas terminé de traiter une demande.
Puisque quelqu'un est en train de réserver sa place, personne d'autre ne touche à rien.
Le problème est que cette réservation peut prendre un peu de temps : il faut vérifier que son auteur est bien inscrit au service, vérifier s'il a un profil "premium", faire l'état des lieux des places encore disponibles et en choisir une, vérifier que les attributs du covoiturage (date, heure, destination) n'ont pas été modifiées depuis que l'on a affiché les informations, etc ...
Et même beaucoup de temps s'il faut repasser par une phase d'inscription au service.
Par conséquent, c'est un risque de messages d'erreurs pour tous ceux qui attendent leur tour, ou l'impression désagréable que le service fonctionne mal ou qu'il est lent.
L'optimiste, c'est de considérer que tout va bien se passer, et de vérifier à la fin que c'était effectivement le cas (et faire machine arrière sinon).
L'un des moyens est de gérer un numéro de version, appliqué au covoiturage.
Voici le déroulement :
- On récupère le numéro de version au tout début du traitement, en même temps que les autres informations (dont le nombre de places restantes).
- Puis on déroule le traitementde réservation,
- Et à la fin, on incrémente le numéro de version à condition qu'il soit resté identique à celui qu'on avait au début. Le verrou n'est posé qu'à ce moment, pour exclure tout conflit.
- Si cette condition est OK, on valide toutes les modifications apportées au covoiturage ("commit"), sinon on les annule ("rollback").
L'avantage de cette méthode est de limiter le temps de verrouillage, en pariant qu'il y aura peu de conflits.
L'inconvénient est que l'utilisateur peut croire que tout va bien, jusqu'à s'apercevoir à la toute fin que "désolé, ce covoiturage n'est plus disponible".
Un des moyens de le prévenir est d'afficher le nombre de personnes actuellement en train de consulter le même covoiturage.
C'est un truc souvent utilisé pour les réservations d'hôtels ou de vols. En prime, ça suscite l'effet d'urgence tant prôné dans les manuels de marketing !
Références :
- Les schémas proviennent de cet article, qui détaille l'implémentation avec Elixir et Postgresql : https://blog.appsignal.com/2021/07/13/building-aggregates-in-elixir-and-postgresql.html
- Le pattern "Aggregate" : https://martinfowler.com/bliki/DDD_Aggregate.html
