Architecture des données

Bienvenue dans le chapitre 7 : Architecture des données. Le code peut être réécrit en quelques mois, mais les données vivent pendant des décennies. Les comptes clients, les grands livres, les commandes et les dossiers médicaux survivent à chaque framework et à chaque service qui les touche. Déplacer ces données est lent, risqué et coûteux. C’est pourquoi les décisions de ce chapitre comptent parmi les plus importantes que prend un architecte : elles sont difficiles à défaire, larges dans leur portée, et déterminantes pour la disponibilité, les performances et la modifiabilité.

Ce chapitre s’adresse aux développeurs et aux architectes qui connaissent déjà les styles distribués du chapitre 6, et qui doivent maintenant prendre des décisions solides et défendables sur les données. Il s’appuie directement sur le chapitre 6. Découper le code en services est la moitié facile. Dès qu’il y a plusieurs services, quelqu’un doit décider qui peut modifier chaque donnée, comment les autres la voient, et ce qui se passe quand ses copies divergent. Il suppose aussi acquises les bases des bases de données vues dans la section du chapitre 0 sur le stockage des données. Si les tables, les requêtes et les transactions sont nouvelles pour vous, commencez par là. Et il mène au chapitre 8, qui protège ces données et le système dans son ensemble.

Le chapitre compte huit sections et suit deux exemples récurrents : une plateforme de livraison de repas, avec son coup de feu du soir, la position des livreurs et les cartes, et une banque en ligne, où perdre ou compter deux fois un seul paiement est inacceptable. La section sept point un, sur la propriété des données, pose la règle la plus importante : chaque fait important doit avoir un seul système de référence et un seul rédacteur. Elle explique pourquoi une base de données partagée couple les services, aussi proprement que leur code soit séparé. La section sept point deux passe en revue les bases relationnelles, orientées documents, clé-valeur, orientées graphe, de séries temporelles et d’autres encore. Elle soutient que la base relationnelle reste le bon choix par défaut pour les systèmes de référence, et que chaque base spécialisée doit mériter sa place. La section sept point trois va au-delà du sigle bien connu ACID pour examiner les anomalies que provoque la concurrence, comme les mises à jour perdues et le write skew, et ce que les niveaux d’isolation garantissent réellement dans les bases de données les plus répandues. La section sept point quatre explique comment les bases de données copient et répartissent les données entre plusieurs machines, ce que le retard de réplication et le failover font à l’exactitude, et comment choisir une clé de sharding à partir des chiffres.

Voici la première et la plus importante idée du chapitre, tirée de la section sept point un. L’image compare deux façons de fournir leurs données à trois services. À gauche, les services de commandes, de cuisine et de livraison lisent et écrivent tous dans une même base de données partagée de commandes, de cartes et de livreurs. N’importe quel service peut modifier n’importe quelle table : chaque table est donc une interface publique, et toute modification de schéma exige une mise en production coordonnée. À droite, chaque service a sa propre base de données. Chaque schéma est privé, il n’y a pas de jointures entre bases de données, et les données ne franchissent les frontières que par des appels d’API et des événements. Désormais, chaque propriétaire peut modifier son schéma seul. Cette indépendance a un prix. Les jointures, les transactions et l’intégrité référentielle entre services doivent être remplacées par des API, des événements, des sagas et des pipelines de reporting, et la section montre comment lire des données dont vous n’êtes pas propriétaire.

La seconde moitié du chapitre porte sur les données dérivées des systèmes de référence, et sur le changement dans le temps. La section sept point cinq couvre la séparation des responsabilités entre commandes et requêtes, ou CQRS, et l’event sourcing. Ces approches séparent le modèle qui accepte les changements des modèles qui répondent aux requêtes, et stockent un historique d’événements plutôt que l’état courant, au prix d’une complexité bien réelle. La section sept point six porte sur la mise en cache : conserver des copies au plus près de l’endroit où elles sont nécessaires, du navigateur à la base de données, y compris les ruées sur le cache qui peuvent faire tomber un système quand une entrée très demandée expire. La section sept point sept part du constat que tout schéma, qu’il s’agisse de tables de base de données, de charges utiles d’API ou d’événements, changera pendant que le système fonctionne. Les règles de compatibilité et le patron expansion-contraction permettent ce changement sans interruption de service. Enfin, la section sept point huit passe de la conduite de l’activité à sa compréhension : entrepôts de données, data lakes et lakehouses, traitement de flux, et data mesh, une manière d’organiser les données analytiques autour des domaines.

Les sections forment une chaîne, et ce schéma de la section sept point deux montre cette chaîne dans une plateforme de livraison de repas. Commandes et Cartes écrivent chacun dans leur propre base de données PostgreSQL. Ce sont les deux seuls systèmes de référence, et ils contiennent les commandes, les paiements et les cartes. Tout le reste est une copie délibérée. La position des livreurs est conservée dans une base clé-valeur en mémoire et expire au bout de trente secondes. La capture des données modifiées copie les changements de carte dans un moteur de recherche, avec quelques secondes de retard. Et un entrepôt de données reçoit les commandes, les cartes et un échantillon des points de trajet des livreurs pour l’analytique, avec quelques heures de retard. Chaque copie est plus rapide ou plus pratique pour un certain usage, chacune est périmée dans une certaine mesure, et chacune peut être reconstruite.

Cette chaîne mène à l’idée à retenir de ce chapitre. Pour chaque donnée importante, vous devez pouvoir répondre à trois questions. Premièrement, qui est son seul rédacteur ? Deuxièmement, où ses règles sont-elles appliquées ? Et troisièmement, à quel point chacune de ses copies peut-elle être périmée ? La plupart des problèmes de données des systèmes réels, comme des commandes dont l’état recule, des rapports en désaccord avec le grand livre, des doubles réservations ou des clients qui ne voient pas leurs propres modifications, viennent de ce qu’on n’a pas répondu délibérément à l’une de ces questions. Les techniques de ce chapitre sont des moyens d’y répondre correctement, et chacune d’elles est un compromis entre cohérence, disponibilité, performances, coût et effort d’exploitation du système.

À la fin du chapitre, vous saurez attribuer la propriété des données, y compris dans les cas délicats où plusieurs services veulent écrire les mêmes données. Vous saurez choisir une base de données pour chaque jeu de données, selon sa forme, ses schémas d’accès, ses besoins de cohérence et son échelle, et justifier le coût de chaque base supplémentaire. Vous saurez protéger un chemin lecture-modification-écriture par verrouillage, vérification de version ou transactions sérialisables. Et vous saurez planifier des modifications de schéma, avec des règles de compatibilité et l’expansion-contraction, afin qu’elles n’exigent aucune interruption de service.

Comme les sections forment une chaîne, mieux vaut les lire dans l’ordre. Mais chacune se suffit aussi à elle-même : vous pouvez donc aller directement à la section dont vous avez besoin. Comptez environ trois heures et demie pour lire tout le chapitre. À la fin de chaque section, vous trouverez des questions d’autoévaluation. Répondez-y de tête avant de regarder les réponses ; elles vous montrent rapidement ce que vous avez retenu. Quand vous êtes prêt, un test facultatif du chapitre vous attend ; il dure environ quarante-cinq minutes. Il comporte vingt questions à choix multiples et deux réponses rédigées. La note de réussite est de quatre-vingts pour cent.

Voilà la structure du chapitre. Commencez par la section sept point un, sur la propriété des données et la base de données par service, où la règle d’un seul rédacteur pour chaque fait est exposée en détail. À très vite.