Propriété des données et base de données par service

Pourquoi la propriété est la première question sur les données

Le chapitre 6 a découpé les systèmes en services déployés, mis à l’échelle et modifiés indépendamment. Le code se découpe assez facilement ; les données, non. Une commande fait référence à un client, à un plat de la carte, à un restaurant et à un livreur, et chaque équipe veut lire, et souvent modifier, une partie de ces informations. La question la plus importante d’une architecture de données distribuée n’est donc pas de savoir quelle base de données acheter, mais à qui appartient chaque donnée : quel composant a le droit de la modifier, lequel applique ses règles, et comment tous les autres peuvent la voir.

La propriété compte parce que les données survivent au code. Les services sont réécrits tous les quelques ans ; les comptes clients, les grands livres et les dossiers médicaux sont conservés pendant des décennies. Se tromper sur la propriété produit le type coûteux de dette architecturale : deux services qui ne peuvent pas être mis en production séparément parce qu’ils partagent des tables, un champ de statut que trois équipes écrasent tour à tour, ou un rapport mensuel que personne ne peut reproduire parce que les chiffres viennent de cinq copies discordantes des mêmes données.

Cette section utilise deux exemples récurrents qui reviennent tout au long du chapitre : une plateforme de livraison de repas (clients, restaurants, livreurs, commandes) et une banque en ligne (clients, comptes, paiements, grand livre).

Système de référence et propriété des données

Un système de référence (system of record) est la source qui fait autorité pour une donnée : l’endroit dont la valeur l’emporte quand les copies divergent. Dans la banque, le grand livre central est le système de référence des soldes des comptes ; le solde affiché dans l’application mobile, celui du cache du moteur antifraude et celui du chargement de la nuit dernière dans l’entrepôt de données sont tous des copies. Dans la plateforme de livraison de repas, le service de carte propre au restaurant est le système de référence des prix, même si l’index de recherche, le cache hors ligne de l’application mobile et les lignes de commande en détiennent tous des copies.

La propriété des données transforme cela en responsabilité. Le composant propriétaire (et l’équipe qui en a la charge) est le seul à écrire les données, à faire respecter leurs invariants (des règles qui doivent toujours être vraies, comme une écriture du grand livre n’est jamais modifiée, seulement contrepassée), à décider de leur schéma et à les publier pour les autres au moyen d’une interface qu’il contrôle. La propriété est une décision de conception, pas une propriété de la base de données : deux services peuvent résider sur le même serveur de base de données et avoir malgré tout une propriété claire, et deux services dotés de bases séparées peuvent encore se disputer les mêmes faits si la frontière entre eux est mal tracée.

Une règle utile tirée de Software Architecture: The Hard Parts (Neal Ford, Mark Richards, Pramod Sadalage et Zhamak Dehghani, 2021) veut que le service qui écrit dans une table en soit le propriétaire. La lecture se partage à peu de frais ; l’écriture, non, car celui qui écrit doit faire respecter les règles.

La base de données partagée, et pourquoi elle couple les services

La façon la plus simple de permettre à plusieurs applications de travailler sur les mêmes données est de leur donner à toutes accès à une seule base de données. Martin Fowler a appelé cela une base de données d’intégration (2004) : une base qui constitue le point d’intégration entre des applications, par opposition à une base de données d’application qui ne sert qu’une seule application. Elle semble séduisante : aucune API à construire, les jointures fonctionnent sur tout, et une seule transaction peut mettre à jour ensemble les commandes et les paiements. Le verdict de Fowler, partagé par la plupart des architectes, est qu’il faut éviter les bases de données d’intégration, car le couplage qu’elles créent est profond et en grande partie invisible.

Considérez les formes de couplage qu’elle introduit. Couplage de schéma : chaque table et chaque colonne est de fait une API publique. Renommer orders.state en orders.status casse tout service qui la lit, et personne ne peut savoir avec certitude lesquels le font, car les requêtes SQL sont dispersées dans de nombreuses bases de code, rapports et tableurs. Couplage de déploiement : une modification de schéma doit être coordonnée entre toutes les équipes qui touchent la table, si bien que des services censés être mis en production indépendamment le sont ensemble. Couplage sémantique : le schéma doit servir tous les clients, il devient donc plus général et plus confus (Fowler note qu’il finit par tenter d’unifier des concepts qui relèvent de contextes délimités distincts), et les règles métier d’une table finissent dupliquées, de façon incohérente, dans chaque service qui l’écrit. Couplage à l’exécution : la requête de reporting lente ou le traitement par lots gourmand en verrous d’un service dégrade tous les autres services, et la base de données devient un point de défaillance unique partagé et un plafond pour le nombre de connexions.

Rien de tout cela n’est fatal pour une application unique ou pour un monolithe modulaire dont les modules respectent les tables les uns des autres, ni pour l’architecture à base de services à gros grain, dans laquelle une poignée de services de domaine partagent souvent délibérément une base de données. Cela devient un problème quand les équipes attendent une déployabilité indépendante mais conservent les tables partagées, ce qui est une voie classique vers un monolithe distribué.

Base de données par service

L’alternative, associée aux microservices, est le patron base de données par service : les données persistantes de chaque service lui sont privées, et les autres services ne peuvent y accéder que par l’API du service ou les événements qu’il publie. Le catalogue de patrons de Chris Richardson (microservices.io) note que cela ne signifie pas forcément un serveur distinct par service. Il existe trois niveaux de séparation, et la ligne importante est la première.

Les avantages sont le reflet des coûts de la base partagée : les propriétaires modifient librement leurs schémas, mettent à l’échelle et règlent leurs bases indépendamment, choisissent le bon type de base de données et circonscrivent les défaillances. Les coûts sont réels et doivent être indiqués dans tout enregistrement de décision. Les jointures entre services disparaissent et doivent être remplacées par une composition d’API ou des données répliquées. Une seule transaction ACID ne peut plus couvrir à la fois les commandes et les paiements ; les changements entre services deviennent des sagas avec des étapes de compensation. L’intégrité référentielle entre services (chaque commande pointe vers un client réel) n’est plus garantie par des clés étrangères. Le reporting exige un pipeline distinct. Et il y a davantage de bases de données à sauvegarder, à mettre à jour et à superviser.

The Hard Parts présente la décision comme un équilibre de forces. Les désintégrateurs poussent à séparer les données : le contrôle des changements (combien de services cassent quand une table change), les limites de connexions, la scalabilité, la tolérance aux pannes, le souhait d’unités déployables indépendamment et le besoin de types de bases de données différents. Les intégrateurs rassemblent les données : les relations qui exigent l’intégrité référentielle, et les opérations qui ont réellement besoin d’une seule transaction atomique. Si deux tables sont toujours modifiées ensemble dans une même transaction et n’ont pas de vie indépendante, c’est un indice fort qu’elles appartiennent au même propriétaire.

Quand plusieurs services écrivent les mêmes données

Les questions de propriété deviennent difficiles quand plus d’un service modifie légitimement la même entité. The Hard Parts distingue trois situations. En propriété unique, un seul service écrit dans la table, et il en est simplement le propriétaire. En propriété commune, la plupart des services écrivent dans la même table (un journal d’audit ou un ensemble de paramètres de configuration, par exemple) ; la réponse habituelle est de créer un service dédié qui possède les données et de donner une API à tous les autres, souvent asynchrone pour ne pas ralentir les rédacteurs. En propriété conjointe, un petit nombre de services, généralement deux, écrivent dans la même table, le plus souvent au sein du même domaine. Le livre propose quatre techniques pour la propriété conjointe.

Aucune technique n’est gratuite, et la bonne dépend de la fréquence à laquelle les données changent, de la rigueur de leurs règles et du degré d’indépendance nécessaire aux équipes. En pratique, la délégation est la réponse la plus courante pour les entités métier dotées d’un cycle de vie (commandes, paiements, réservations), la scission de table fonctionne bien quand les colonnes écrites conjointement sont en réalité des faits différents qui se trouvaient stockés ensemble, et la consolidation est la réponse honnête quand les deux services ont été découpés trop finement dès le départ.

Lire des données dont vous n’êtes pas propriétaire

Une fois la propriété établie, tous les autres services ont encore besoin de lire les données. L’écran de la cuisine a besoin des instructions de livraison du client ; le moteur antifraude a besoin des paiements récents du compte. Il existe quatre grandes options, et chacune arbitre entre fraîcheur et couplage. Notez que les conceptions pilotées par les événements, traitées au chapitre 6, fournissent la troisième et la quatrième.

Fowler appelle la quatrième option transfert d’état porté par les événements (event-carried state transfer) : des événements comme MenuItemPriceChanged transportent les nouvelles valeurs, si bien que les consommateurs n’ont pas besoin de rappeler le propriétaire. Un mécanisme apparenté, la capture des données modifiées (CDC), lit le journal de la base de données du propriétaire et transforme chaque changement validé en événement, ce qui évite le problème de la double écriture (écrire dans la base de données et publier un événement séparément, si bien que l’un peut réussir et l’autre échouer). L’outbox transactionnelle, qui résout le même problème depuis l’intérieur de l’application, est traitée avec les sagas.

Le reporting transversal aux services

La base de données par service complique une tâche ancienne : le rapport transversal. Le chiffre d’affaires par restaurant et par semaine, net des remboursements, ventilé par type de livreur exige les commandes, les paiements, les restaurants et les livraisons. Le produire en appelant quatre API page par page est lent et fait peser la charge du reporting sur les services opérationnels. Interroger directement leurs bases de données réintroduit par la petite porte le couplage de la base partagée.

La réponse habituelle consiste à séparer le reporting des opérations. Fowler a décrit une base de données de reporting : une base distincte, conçue pour les requêtes et alimentée par les systèmes opérationnels, que les utilisateurs du reporting peuvent lire librement. Aujourd’hui, il s’agit généralement d’un entrepôt de données ou d’un lakehouse alimenté par CDC ou par des événements, traité dans analytique et streaming. Pour de petites vues en quasi temps réel au sein du produit (le tableau de bord des commandes du jour d’un restaurant), un service peut construire son propre modèle de lecture à partir d’événements, l’idée à la base de CQRS. Dans les deux cas, les pipelines qui alimentent le reporting dépendent des structures de données des propriétaires, et c’est pourquoi ils ont besoin de contrats.

Contrats de données

Un contrat de données est un accord explicite et versionné entre le propriétaire d’un jeu de données et ses consommateurs. Il précise le schéma (champs, types, lesquels peuvent être nuls), la signification de chaque champ (amount est-il en pence ou en livres, TVA comprise ou non ?), les attentes de qualité (aucun identifiant de commande en double, au plus 0,1 % de lignes sans restaurant), les niveaux de service (fraîcheur des données, durée de conservation), le propriétaire et la manière dont les changements sont annoncés. Il applique l’idée d’un contrat d’API aux données qui circulent entre équipes au moyen d’événements, de flux CDC et de tables d’entrepôt de données.

Les contrats sont surtout utiles lorsqu’ils sont lisibles par une machine et vérifiés automatiquement : un pipeline qui rejette une modification de schéma qui casserait des consommateurs enregistrés, ou un test qui échoue quand une règle de qualité est enfreinte. L’Open Data Contract Standard (ODCS), maintenu par le projet Bitol au sein de la Linux Foundation AI & Data, définit un format YAML couvrant le schéma, les règles de qualité, les niveaux de service, les rôles et les canaux d’assistance. Les contrats de données ne sont pas gratuits : quelqu’un doit les rédiger et les maintenir, et des contrats trop stricts ralentissent le changement. The Hard Parts oppose les contrats stricts (précis, vérifiables, fortement couplants) aux contrats souples (plus faciles à faire évoluer, mais demandant davantage de tests), et propose comme voie médiane les contrats pilotés par le consommateur, dans lesquels les consommateurs indiquent ce qu’ils utilisent réellement. La manière de modifier un schéma sans casser les consommateurs fait l’objet de l’évolution des schémas.

Erreurs courantes

Découper les services mais garder les tables partagées. Les équipes subissent le coût opérationnel de la distribution sans l’indépendance qu’elle devait apporter. Si des services ne peuvent pas être déployés sans coordonner une modification de schéma, ils ne sont pas indépendants. Les services d’entité. Un CustomerService qui n’est rien d’autre que des opérations de création, lecture, mise à jour et suppression sur une table, appelé par tous les autres services, est une base de données partagée avec de la latence en plus ; la propriété doit suivre les capacités métier et leurs règles, pas les noms communs. Des copies qui deviennent discrètement des maîtres. Voir l’avertissement ci-dessus. Ignorer le reporting jusqu’à la fin. Le premier rapport financier après le découpage révèle souvent que personne n’a prévu comment les données seraient rassemblées. Traiter la propriété comme une question purement technique. La propriété est aussi organisationnelle : quelqu’un doit répondre de la qualité des données et, selon la loi de Conway, les frontières de données qui traversent les frontières d’équipes ont tendance à ne pas durer.

Un bon test de toute conception de données consiste à poser, pour chaque fait important, trois questions : qui est le seul rédacteur, où ses règles sont-elles appliquées, et à quel point chaque copie peut-elle être périmée ? Si l’une des réponses est ça dépend ou plusieurs services, la conception n’est pas terminée.