System design : par où commencer dans La Ville

On ne fait pas tenir une ville comme on construit un immeuble

Un immeuble finit par être livré. Ruban coupé, clés remises, chantier fermé, dossier des ouvrages exécutés rangé dans une armoire.

Une ville ne se livre jamais. Elle démarre en hameau, trois fermes et un chemin de terre. Un lotissement s'ajoute, puis une gare, puis vingt mille personnes qui ouvrent leur robinet à la même heure le matin. Personne n'a jamais déclaré une ville terminée.

Un système logiciel qui marche vit la seconde histoire. Le jour où il fonctionne, il grossit. Le jour où il grossit, les décisions prises pour dix utilisateurs se retournent contre lui, et chaque correction fabrique la douleur suivante.

Cette série suit trois mouvements, dans cet ordre : dimensionner la ville, faire circuler, tenir les registres. On chiffre avant de construire, on organise la circulation, puis on s'occupe de ce qui doit rester vrai dans les registres.

Cette page est le plan de lecture. Elle n'enseigne aucune notion en détail : elle donne le chemin, les trois paliers, les six domaines et l'ordre des quinze billets. Garde-la dans un onglet, tu y reviendras entre deux étapes.

Chaque billet ouvre sur La Ville, la même d'un bout à l'autre de la série, transpose ensuite côté informatique, et se termine sur un cas réel publiquement documenté. Celui-ci est le seul sans cas réel. C'est une carte, pas une étape.

System design ou architecture applicative

L'architecture d'une application répond à « quoi construire, avec quoi, et comment le découper ». Quels composants existent, quelle est leur responsabilité, sur quelle pile technique ils reposent, où vivent les données. C'est le terrain de la série Architecture logicielle : par où commencer, qui s'arrête au document d'architecture.

Le system design démarre là où ce système doit encaisser un million d'utilisateurs. Les questions changent de nature : combien de requêtes par seconde, combien d'octets par jour, combien de machines, que se passe-t-il quand l'une d'elles cesse de répondre, et qu'affiche-t-on à l'utilisateur pendant ce temps. On ne raisonne plus sur un composant, mais sur un ensemble réparti dont une partie sera toujours en train de tomber.

La différence pratique tient à ceci : l'architecture applicative se juge au premier jour de production, le system design au millième.

Cinq billets déjà publiés couvrent une partie du terrain, et la série y renvoie plutôt que de les réécrire. SQL ou NoSQL pour le choix du magasin, Couplage lâche, stateless et cache pour le principe du cache, Messagerie inter-services et supervision centralisée pour les quatre modes de communication, Microservices, Event Sourcing et CQRS pour le découpage en services, et Pare-feu, WAF, proxy, IDS/IPS, VPN pour l'angle sécurité des intermédiaires réseau.

Le system design ne remplace pas l'architecture applicative, il la prolonge sous contrainte de charge. Tracer un boulevard avant de savoir où sont les maisons ne rend service à personne.

Les trois questions que pose tout exercice de system design

Un conseil municipal qui examine un plan d'urbanisme revient toujours aux mêmes points. Combien d'habitants dans quinze ans ? Par où passent l'eau, le courrier et les voitures ? Et qu'accepte-t-on de perdre le jour où le pont est coupé par la crue ?

Le system design tient dans ces trois questions. Tout le reste est de la mise en œuvre.

Combien ? C'est l'estimation à la louche, le premier geste du métier. On vise l'ordre de grandeur, à un facteur dix près. Un exemple déroulé en quatre lignes :

100 000 000  utilisateurs inscrits
x 20 %       d'actifs par jour        =  20 000 000  utilisateurs actifs
x 5          requêtes par utilisateur = 100 000 000  requêtes par jour
/ 100 000    (86 400 s, arrondi)      =       1 000  requêtes par seconde

Les 20 % sont une hypothèse assumée, pas une mesure. Changer l'hypothèse change le résultat, et c'est précisément pour ça qu'on l'écrit noir sur blanc au lieu de la garder en tête.

Où passe la donnée ? C'est le chemin d'une requête, de son entrée dans la ville jusqu'au registre qu'elle vient lire ou modifier. Répartiteur de charge, proxy inverse, cache, réseau de distribution de contenu, file de messages, base partitionnée. Chaque intermédiaire raccourcit le trajet de quelqu'un et allonge celui d'un autre.

Qu'accepte-t-on de perdre ? Aucun système réparti ne garantit tout en même temps. Quand le réseau se coupe entre deux centres de données, il faut avoir décidé à l'avance si on refuse le service ou si on répond avec une donnée peut-être périmée. Ce choix se prend en réunion, pas à trois heures du matin.

Personne ne conçoit un système qui ne tombe jamais. On conçoit un système dont on a écrit à l'avance ce qui tombe en premier, et ce que l'utilisateur voit pendant ce temps.

Le fil rouge : La Ville

Une même ville sert de décor à toute la série. Ses canalisations, ses carrefours, son centre de tri postal, son cadastre et son registre d'état civil. Le choix n'est pas décoratif : la ville rend visibles des contraintes que le logiciel dissimule.

Voici la table de correspondance en version courte. Chaque billet en reprend une ou deux lignes, celles qui le concernent.

Une canalisation posée sous une avenue ne se redimensionne pas un mardi après-midi. La même canalisation, en informatique, est invisible, et on découvre son diamètre le jour du pic de trafic.

Une ou deux ancres par section, puis on passe à l'informatique. La métaphore ouvre le sujet, elle ne le démontre jamais.

Le parcours en un schéma

Les six domaines de la série, regroupés en trois paliers, dans l'ordre de lecture. On avance de gauche à droite et on ne passe au palier suivant qu'une fois le précédent digéré.

Les paliers ne classent pas les sujets par difficulté, mais par dépendance. Choisir un algorithme de répartition suppose de savoir combien de requêtes arrivent. Choisir une clé de partition suppose de connaître le volume et le motif de lecture. Chaque étape rend la suivante calculable.

Attaquer la série par le palier 3 revient à découper une base pour une volumétrie qu'on n'a pas encore chiffrée. C'est la façon la plus courante de produire un schéma impressionnant et faux.

Palier 1 : Dimensionner la ville

Avant la première rue, on chiffre. Combien d'habitants dans quinze ans, quel débit d'eau à l'heure de pointe, quelle largeur de voirie. Les canalisations sont l'élément qu'on ne reprendra pas sans rouvrir l'avenue entière, alors on les dimensionne avant de poser le bitume.

Ce palier ne contient presque aucune technologie. Il pose les chiffres, la trajectoire complète et la contrainte théorique dont tout le reste découle. Deux domaines, page du palier : Dimensionner la ville.

Fondamentaux

D'abord l'arithmétique. Trafic, stockage, mémoire, nombre de serveurs : quatre estimations qu'on sait faire en dix minutes au tableau une fois qu'on connaît les ordres de grandeur et les tailles de données usuelles. C'est ce qui décide ensuite du type de base, du besoin de cache et du besoin de partitionner.

Ensuite la contrainte théorique. Trois propriétés, une partition réseau qui n'est pas un choix mais un événement, et un arbitrage à assumer par écrit entre cohérence et disponibilité. Puis la déclinaison côté bases, ACID d'un côté, BASE de l'autre, qui sont les deux faces du même compromis.

1. Cette page, le plan de lecture de la série.
2. L'estimation à la louche : chiffrer avant de construire
3. Le théorème CAP, ACID et BASE : ce qu'on accepte de perdre, à lire après le domaine suivant.

Page du domaine : Fondamentaux.

Mise à l'échelle

L'arc complet en une lecture. Le serveur unique du projet d'école devient une plateforme répartie sur plusieurs centres de données, en neuf étapes. Chaque étape est déclenchée par une douleur précise, et chacune crée la douleur suivante.

C'est la carte que les billets des paliers 2 et 3 détaillent, étape par étape. Le billet traite aussi le piège inverse, celui qu'on voit le plus souvent : franchir une étape des années trop tôt, et payer une complexité que personne n'utilise.

1. De zéro à un million d'utilisateurs, étape par étape

Page du domaine : Mise à l'échelle. Le domaine reprend au palier 3, avec le découpage du stockage.

Ordre de lecture du palier 1 : cette page, l'estimation, la trajectoire de zéro à un million, puis CAP. À la fin, tu n'as choisi aucun produit, et tu sais déjà combien de machines tu vises et ce que tu acceptes de perdre.

Palier 2 : Faire circuler

Les habitants sont là. La question n'est plus de savoir combien ils sont, mais de les faire circuler sans que la ville se bloque à huit heures du matin. Un agent au carrefour, des tourniquets à l'entrée du métro, un centre de tri qui absorbe le courrier de décembre sans que les facteurs travaillent la nuit.

Ce palier traite tout ce qui se trouve entre l'utilisateur et la donnée. Deux domaines, page du palier : Faire circuler.

Trafic

Trois boîtes qu'on confond en permanence : le répartiteur de charge, le proxy direct et le proxy inverse. Trois intermédiaires, mais ils ne regardent pas dans la même direction et ne résolvent pas le même problème. Le billet ajoute les algorithmes de répartition, qui ne se valent pas, et le contrôle de santé.

Puis rapprocher la donnée du lecteur, sur deux étages : le cache distribué devant la base, le réseau de distribution de contenu devant l'application. Le sujet difficile n'y est pas la mise en cache, c'est l'invalidation, la clé chaude et la ruée sur un cache froid.

1. Répartiteur de charge, proxy et proxy inverse
2. Cache distribué et CDN : rapprocher la donnée du lecteur

Page du domaine : Trafic.

Flux & fiabilité

Le découplage par le message d'abord : file classique contre log distribué, topic, partition, décalage du consommateur, garanties de livraison. La clé de partition y décide de l'ordre, donc de la justesse du résultat.

Ensuite les deux mécanismes que tout le monde repousse à plus tard et qui décident du comportement sous stress. Limiter le débit protège le service de ses clients ; l'idempotence protège les données des rejeux que les délais d'attente et les reprises vont provoquer. Enfin la disponibilité. Elle ne s'achète pas : elle se construit en supprimant les points de défaillance uniques, avec l'arithmétique des neuf et les pièges de la bascule.

1. Files de messages et Kafka : découpler pour tenir
2. Limitation de débit et idempotence : encaisser les rejeux
3. Haute disponibilité : redondance, réplication, bascule

Page du domaine : Flux & fiabilité.

Le palier 2 se lit dans l'ordre. Les files de messages supposent qu'on ait compris le rôle d'un intermédiaire, et l'idempotence n'a de sens qu'une fois qu'on sait d'où viennent les rejeux.

Palier 3 : Tenir les registres

Une ville tient parce que ses registres restent justes. Le cadastre dit qui possède quelle parcelle, l'état civil compte une fiche par habitant, et les actes signés chez le notaire engagent plusieurs parties le même jour. Le désordre commence quand deux mairies d'arrondissement enregistrent la même naissance.

Ce palier passe de la circulation au stockage, puis rejoue l'ensemble sur trois systèmes complets. Trois domaines, page du palier : Tenir les registres.

Mise à l'échelle

Quand une base ne tient plus sur une machine, on la découpe. Le découpage est facile ; le redécoupage du jour où on ajoute une machine l'est beaucoup moins. Le hachage cohérent est la réponse, les nœuds virtuels corrigent son défaut, et la clé de partition reste la décision la plus lourde de conséquences de tout le système.

1. Sharding et hachage cohérent : découper sans tout déménager

Page du domaine : Mise à l'échelle.

Données

L'index d'abord, seul levier qui transforme une requête sans toucher au code applicatif, et seul levier dont le coût en écriture est systématiquement oublié. Arbre B+, index groupant, index composite, index couvrant, et la lecture commentée d'un plan d'exécution.

La transaction ensuite. Sur une base, ACID règle la question. Sur cinq services avec cinq bases, plus rien n'est réglé. Deux familles de réponses : le verrouillage coordonné, qui préserve l'atomicité au prix de la disponibilité, et la SAGA, qui abandonne l'atomicité et la remplace par la compensation.

1. L'indexation : ce qui se passe vraiment sous une requête
2. Transactions distribuées : 2PC, 3PC, SAGA et verrous

Page du domaine : Données.

Études de cas

Trois systèmes conçus du début à la fin, dans l'ordre de difficulté. Le raccourcisseur d'URL, que tout le monde croit trivial, sert à dérouler la méthode complète : exigences, estimation, longueur de la clé, génération des identifiants, schéma de données, chemin de lecture. Le magasin clé-valeur rassemble tout le palier 3 dans une seule brique. La messagerie instantanée ajoute le temps réel, l'état de connexion, la présence et l'historique.

1. Concevoir un raccourcisseur d'URL
2. Concevoir un magasin clé-valeur
3. Concevoir une messagerie instantanée

Page du domaine : Études de cas.

Le dernier billet sert de contrôle final. Si son schéma se lit sans rouvrir les quatorze autres, la série a fait son travail.

Les six domaines en un coup d'œil

Le parcours complet, pour retrouver rapidement où aller.

Comment lire la série

Quatre repères avant de commencer.

Commence au palier 1, même si tu opères des systèmes distribués depuis dix ans. On croise beaucoup d'ingénieurs capables de comparer deux répartiteurs de charge et qui calent sur « combien d'écritures par seconde, au juste ». Les deux premiers domaines donnent les chiffres et le vocabulaire que tous les autres réutilisent.

Fais les calculs pendant la lecture, pas après. Chaque fois qu'un billet annonce une estimation, il la pose en entier. Prends trente secondes pour refaire la division à côté : c'est ce geste, répété, qui finit par rendre l'exercice naturel en entretien comme en réunion de cadrage.

Lis le scénario B jusqu'au bout. Chaque billet, sauf celui-ci, se termine sur une panne ou une conception réelle, documentée publiquement par ceux qui l'ont vécue. C'est la partie qui empêche la série de rester un catalogue de bonnes intentions.

Reviens à cette page entre deux paliers. Le schéma du parcours montre d'un coup d'œil ce que tu viens d'acquérir et pourquoi la suite arrive maintenant plutôt qu'avant. Une carte ne sert qu'à ceux qui la ressortent en chemin.

La série vise la compréhension d'un système entier, pas la maîtrise d'un produit. Aucun billet ne remplace une documentation officielle ; tous cherchent à te faire poser la bonne question avant de l'ouvrir.

Points clés

• La série suit trois mouvements, dimensionner la ville, faire circuler, tenir les registres, l'ordre dans lequel une ville se construit vraiment.
• Tout exercice de system design revient à trois questions : combien, où passe la donnée, et qu'accepte-t-on de perdre pendant une panne.
• Trois paliers regroupent six domaines et quinze billets. Les paliers classent par dépendance, pas par difficulté.
• Le palier 1 ne contient presque aucune technologie, et c'est volontaire : on chiffre le système avant de choisir avec quoi le construire.
• Les trois études de cas du palier 3 rejouent l'ensemble de la série sur des systèmes complets, du premier calcul jusqu'au schéma final.

Pour aller plus loin

• L'estimation à la louche : chiffrer avant de construire, la suite immédiate de cette page.
• Architecture logicielle : par où commencer sur Le Chantier, la série amont, pour tout ce qui se décide avant la question de la charge.
• Les trois pages de palier regroupent leurs billets au fil des publications : Dimensionner la ville, Faire circuler, Tenir les registres.
• La section System Design rassemble les quinze billets à mesure qu'ils sortent.
• Designing Data-Intensive Applications, de Martin Kleppmann, si tu veux le traitement long et rigoureux des sujets abordés aux paliers 2 et 3.