Données en retard : choisir ce que chaque opération peut accepter

Un client vient de s'inscrire, mais la facturation ne le trouve pas encore dans sa copie des données. Faut-il refuser la facture, attendre ou la préparer pour plus tard ? La réponse dépend du besoin métier. Une donnée en retard peut être acceptable pour un affichage et bloquante pour une décision. Il faut préciser ce que chaque opération peut faire dans cette situation.

Un décalage peut apparaître dans une seule application

Supposons que l'inscription enregistre le client immédiatement et qu'un traitement de fond mette ensuite à jour la copie utilisée par la facturation. Entre les deux, le client existe dans la source mais reste absent de cette copie.

Ce décalage peut survenir sans panne réseau, y compris lorsque tous les modules sont livrés ensemble. Il vient ici d'une mise à jour différée. Si le traitement s'arrête, un retard temporaire peut devenir durable.

Le théorème CAP traite plus précisément des garanties d'un système distribué face à des pertes de communication. Il ne transforme pas tout retard en partition réseau. Son interrogation sur la réponse possible avec une information incomplète aide néanmoins à poser des questions de conception similaires.

Repérer les endroits où les données peuvent manquer

Une copie de lecture, un cache ou un service externe peut fournir une information ancienne ou indisponible. Pour concevoir le comportement de l'application, il faut savoir quelle information fait référence et comment elle arrive jusqu'au traitement qui en a besoin.

• Entre domaines métier. La facturation et la gestion des clients peuvent mettre à jour leurs informations séparément.
• Entre écriture et lecture. Avec CQRS, une vue préparée pour un écran peut être actualisée après la modification des données de référence.
• Entre modules. Une tâche de fond ou un cache peut introduire du retard, même sans séparation en services.
• Entre services. Une panne de communication peut empêcher une vérification ou une mise à jour.
• Avec un fournisseur externe. Une passerelle de paiement ou un service de messagerie peut devenir lent ou indisponible.

Choisir le sens d'une dépendance détermine ce que chaque module connaît. Il faut ensuite décider ce qu'il fait lorsque l'information attendue n'arrive pas.

La conséquence métier détermine le retard acceptable

La liste des clients peut accepter un bref décalage après une inscription. Une facture qui engage une identité ou une adresse précise peut nécessiter une vérification auprès de la source avant d'être émise. Les deux opérations utilisent pourtant les mêmes données.

Une règle qui doit rester vraie, par exemple « facturer le bon destinataire », est un invariant. Il faut identifier cette règle, puis déterminer quelles informations sont nécessaires pour la vérifier.

Je conseille de discuter aussi des erreurs que le métier accepte de corriger. Dans son retour sur CAP, Brewer cite les distributeurs de billets pour illustrer un fonctionnement qui peut privilégier le service, avec un risque financier limité et une régularisation ultérieure. C'est un exemple de compromis, pas une règle applicable à tous les paiements.

Bloquer, limiter le service ou accepter un décalage

Ces trois conduites forment une grille pratique. Elles peuvent varier avec la durée de l'incident : un affichage peut utiliser une copie récente pendant quelques secondes, puis devenir indisponible si elle est trop ancienne.

Le délai acceptable doit être explicite. « Un peu de retard » ne permet ni de configurer une alerte ni de décider quand changer de comportement. Un objectif chiffré appartient au service concerné et doit être validé selon les conséquences pour ses utilisateurs.

Décrire aussi ce que voit l'utilisateur

Pour une facture mise en attente, indiquez qu'elle n'est pas encore émise. Pour un stock ancien, affichez la date de vérification. Pour une action refusée, expliquez si l'utilisateur peut réessayer ou s'il doit choisir une autre démarche.

Un tableau par opération aide à rendre ces choix vérifiables :

• La donnée nécessaire et sa source de référence.
• La fraîcheur et le délai de réponse attendus.
• Le comportement si la source ne répond pas.
• Le message présenté à l'utilisateur.
• Le moyen de détecter le retard et de reprendre le traitement.

Cette méthode dépasse le champ strict de CAP. Kleppmann et Abadi invitent justement à éviter les classifications trop larges. Un retard prévu, une erreur de traitement et une coupure réseau peuvent gêner la même opération, mais ils ne se diagnostiquent ni ne se réparent de la même façon.

Sources

• M. Kleppmann, Please stop calling databases CP or AP, 2015.
• E. Brewer, CAP Twelve Years Later: How the « Rules » Have Changed, IEEE Computer, février 2012.
• D. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design, IEEE Computer, février 2012.