La réplication consiste à conserver des copies des mêmes données sur plusieurs machines, afin que le service puisse continuer à fonctionner en cas de panne de l’une d’elles et supporter une charge de trafic supérieure à ce qu’une machine unique pourrait gérer.
Pour illustrer cela concrètement, nous utiliserons un service simple de profil utilisateur prenant en charge les requêtes GET /profile/{user_id} et PUT /profile/{user_id} pour lire et mettre à jour le nom, l’URL de la photo et les paramètres d’un utilisateur.
Un seul serveur suffit tant que la base de données des profils ne devient pas un point de défaillance unique ni un goulot d’étranglement pour le débit, car chaque opération de lecture et d’écriture dépend du bon fonctionnement et de la rapidité de cette machine unique.
La vue suivante établit notre configuration de référence, permettant aux leçons ultérieures de la soumettre à des contraintes et d’observer où elle finit par céder.
Dans ce scénario de référence, les clients sollicitent le service API, lequel effectue des lectures et des écritures sur une base de données unique ; par conséquent, une panne de la base interrompt à la fois les lectures et les écritures, tandis qu’un pic de trafic sature un processeur et un disque uniques.
C’est cette contrainte qui fait de la réplication un sujet de conception clé lors des entretiens : l’interviewer se concentrera sur le comportement du système en cas de panne ou de forte charge, plutôt que sur l’implémentation technique d’un point de terminaison spécifique.
La réplication ne se résume pas à une fonctionnalité unique. Il s’agit d’un ensemble de choix qui dépendent des garanties que le système doit offrir en cas de défaillance de certains composants.
Dans le cas d’un service de gestion de profils, l’interviewer commence généralement par vérifier si le candidat est capable d’identifier les quelques exigences susceptibles de modifier le modèle de réplication, avant d’aborder des technologies spécifiques.
Les paramètres à définir correspondent directement aux flux de lecture et d’écriture.
Une fois ces éléments définis, la réplication cesse d’être un concept abstrait pour devenir un contrat concret ; par exemple, déterminer si une requête GET /profile est autorisée à renvoyer une ancienne photo pendant quelques secondes après la réussite d’une requête PUT /profile.
Une fois les exigences établies, la configuration minimale avec réplication consiste à ajouter une seule copie supplémentaire de la base de données et à définir la manière dont les mises à jour sont propagées entre elles.
Pour l’instant, nous conservons la sémantique applicative telle quelle. Les clients continuent d’interagir avec une couche API unique, et cette couche émet toujours une écriture logique qui ne doit pas se scinder silencieusement en versions contradictoires.