Tech • IA • Robotique
Préparation à l’entretien de conception de systèmes pour débutants (cours complet)
INTRO
Une approche pratique d’entretien de conception de systèmes consiste à transformer des consignes vagues en un périmètre concret, à estimer l’échelle, à défendre les compromis, et à résoudre le goulet d’étranglement le plus difficile plutôt qu’à dessiner l’architecture la plus imposante.
POINTS CLÉS
Ce que les recruteurs évaluent réellement
Les candidats solides sont jugés moins sur des technologies mémorisées que sur le jugement en situation d’ambiguïté, la profondeur technique, la communication et la collaboration. Les signaux clés sont leur capacité à clarifier le problème, à expliquer clairement les compromis et à s’adapter lorsque les hypothèses changent. Les échecs fréquents consistent à passer directement à l’architecture et à surconcevoir avec caches, files, shards et complexité multi-région avant d’avoir prouvé leur utilité.
Cadre en six étapes
Un cadre reproductible aide à structurer une discussion de conception de 45 minutes: clarifier les exigences, faire des estimations approximatives, définir les API, esquisser une conception de haut niveau, approfondir le composant le plus difficile, puis terminer par les goulets d’étranglement et le passage à l’échelle. La répartition du temps est d’environ 5 minutes pour les exigences, 5 pour les estimations, 5 pour les API, 10 à 15 pour la conception de haut niveau, 10 à 15 pour les approfondissements, et les 5 dernières pour l’analyse des défaillances et les options de montée en charge.
Les questions de clarification doivent changer la conception
Les bonnes questions sont celles dont les réponses modifient le périmètre, l’échelle ou l’architecture. Exemples utiles: le nombre d’utilisateurs et sa croissance, si le système est surtout orienté lecture ou orienté écriture, quelles données ne peuvent pas être perdues, et quelle latence compte le plus. Des questions faibles, comme demander s’il faut utiliser SQL ou NoSQL, ou si le système doit être scalable, délèguent le jugement de conception au lieu de le démontrer.
Le périmètre compte plus que la taille du diagramme
Dans la conception d’un service de partage de photos, demander si l’accent porte sur l’envoi de photos ou la génération du fil d’actualité peut transformer une consigne vague en problème solvable. Limiter le périmètre à la publication de photos, au suivi d’utilisateurs et au chargement du fil d’accueil produit une conception plus petite mais correcte, tandis qu’essayer d’inclure la recherche, les messages directs et tous les cas limites mène souvent à un système impressionnant mais hors sujet.
Le raccourcisseur d’URL comme problème modèle
Un service basique de liens courts peut être cadré par trois questions qui changent la conception: si les utilisateurs peuvent choisir des alias personnalisés, si les liens expirent, et si des analyses de clics sont requises. Une version concrète peut rester simple: pas de liens personnalisés, pas d’expiration, analytique facultative. Cela réduit l’exigence centrale à créer un code court et à rediriger les utilisateurs de l’URL courte vers l’URL d’origine.
Les estimations révèlent le vrai goulet d’étranglement
Avec 1 million de nouveaux liens créés par jour, le chemin d’écriture n’est que d’environ 12 écritures par seconde, ce que presque toute base de données peut gérer. Si chaque lien court reçoit environ 1 000 clics, le service fait face à près de 1 milliard de redirections par jour, soit plus de 11 000 lectures par seconde. Sur 10 ans, cela représente environ 3,6 milliards de liens stockés, ce qui rend le système clairement orienté lecture.
Modèle de données simple, choix de base délibéré
L’API essentielle n’a besoin que d’une opération de création de lien et d’une opération de redirection. Le modèle de données est une correspondance un-à-un entre code court et URL longue, une forme bien adaptée à un stockage relationnel comme Postgres avec un index sur le code court. La justification vient du modèle d’accès: recherche simple par clé, pas de jointures, et pas besoin d’opérations complexes sur plusieurs lignes.
Génération de codes courts uniques
Deux approches principales existent: le hachage et les compteurs. Le hachage peut produire des collisions lorsque différentes URL partagent les mêmes premiers caractères, ce qui devient plus coûteux à mesure que la base se remplit. Un compteur global encodé en base62 évite entièrement les collisions; un code de 7 caractères fournit environ 3,5 billions de combinaisons, bien au-delà des 3,6 milliards nécessaires sur une décennie.
La conception par compteur crée de nouveaux risques
Un compteur introduit deux faiblesses à traiter. D’abord, des valeurs séquentielles sont prévisibles; le nombre doit donc être transformé par un mélange secret réversible avant encodage pour donner aux liens une apparence aléatoire. Ensuite, des requêtes concurrentes de création peuvent se disputer la même valeur; la mise à jour du compteur doit donc être protégée par un verrou ou un mécanisme atomique équivalent.
Le cache est l’optimisation centrale
Un trafic viral crée un problème de clé chaude lorsque des millions d’utilisateurs demandent le même lien court. Placer Redis devant la base permet au premier échec de charger depuis Postgres, puis aux requêtes suivantes d’être servies depuis le cache en moins d’une milliseconde. C’est particulièrement sûr ici, car les correspondances d’URL sont immuables après création; le problème habituel d’obsolescence du cache disparaît donc presque entièrement.
Le choix de redirection affecte le contrôle et l’analytique
Une redirection 301 est plus rapide et permet aux navigateurs de mémoriser la destination, ce qui réduit la charge future sur le service. Mais cela retire aussi de la visibilité sur les clics suivants et rend plus difficile la désactivation de liens malveillants. Une redirection 302 fait continuer les requêtes à travers le service, préservant l’analytique et le contrôle opérationnel, au prix d’un traitement de trafic plus important.
CONCLUSION
La leçon centrale est qu’une bonne performance en conception de systèmes vient d’un cadrage discipliné et de compromis explicites, non du nombre de composants dessinés. En pratique, les meilleures conceptions commencent simplement, identifient le vrai goulet d’étranglement, puis n’ajoutent de la complexité que lorsque l’échelle ou les exigences produit le justifient.
Explique-moi