Entretien system design : arrête de mémoriser des architectures

On te colle devant un tableau blanc. « Conçois Twitter. » 45 minutes. Pas de bonne réponse unique. Juste toi, un feutre qui marche à moitié, et quelqu’un en face qui observe comment tu réfléchis.

Mes premiers essais ? Catastrophiques. Je fonçais bille en tête sur les composants, des flèches dans tous les sens, et au bout de vingt minutes j’avais un truc illisible. Le problème venait pas de mes connaissances. Il venait de l’absence totale de structure.

Le system design n’est pas un coding interview (et c’est tant mieux)

Franchement, c’est la confusion la plus répandue. Au coding interview, tu connais les règles : un problème, des contraintes, une solution optimale. Le system design fonctionne à l’envers.

On évalue ta capacité à naviguer l’ambiguïté. Deux candidats proposent des architectures radicalement différentes — les deux décrochent le poste. Ce qui fait la différence, c’est la qualité de tes compromis et ta façon de structurer le problème avant de le résoudre.

Le truc c’est que 90 % des devs préparent ça comme un exam. Ils mémorisent des schémas. Sauf que l’évaluateur veut ton processus de pensée, pas un diagramme récité. Mémoriser des architectures, c’est la pire stratégie possible — et pourtant c’est ce que tout le monde fait.

URDGE : cinq étapes, toujours dans cet ordre

Understand, Requirements, Design, Go Deeper, Evaluate. Rien de révolutionnaire sur le papier. Mais appliqué avec rigueur, ça change complètement la donne.

Comprendre avant de dessiner. Les cinq premières minutes sont les plus importantes. Et personne ne les utilise correctement. Pose des questions — beaucoup. Qui sont les utilisateurs ? Combien ? Quelles contraintes de latence ? On parle d’une seule région ou de déploiement mondial ?

Exemple : on te dit « conçois un raccourcisseur d’URL ». Avant de toucher au feutre, clarifie. Faut-il gérer l’analytics ? Les URL expirent-elles ? Quel volume de créations par seconde ? Ces réponses changent radicalement ton architecture. Un raccourcisseur pour 1 000 utilisateurs et un pour 100 millions, c’est pas le même système.

Poser les exigences chiffrées. Tu transformes tes clarifications en chiffres concrets. Côté fonctionnel : 3 à 5 features, pas plus. En 45 minutes tu ne peux pas tout couvrir, sois sélectif. Côté non fonctionnel : scalabilité, disponibilité (99.9 % ou 99.99 % — ça change tout), latence p99, modèle de cohérence.

Et les estimations de capacité, ne les saute jamais. 100 millions d’URLs à 500 octets, ça fait environ 50 Go. Ces calculs « au dos de l’enveloppe » dictent ton choix de base de données, de cache, de partitionnement. Sans eux, tes décisions sont arbitraires.

Dessiner l’architecture haut niveau. Maintenant tu dessines — mais en restant macro. API Gateway, load balancer, services, base de données, cache, file de messages. Tu places les briques, tu traces les flux principaux. Pour le raccourcisseur : un write path (URL longue vers identifiant court vers stockage) et un read path (URL courte vers cache vers base vers redirection). Simple. C’est exactement ce qu’on attend à ce stade.

Creuser là où ça compte. C’est ici que tu te démarques vraiment. Choisis deux ou trois composants et va en profondeur. Génération d’identifiants ? Compare Base62, Snowflake, hachage avec gestion de collisions — en termes de performance, d’unicité, de complexité opérationnelle. Stratégie de cache ? Cache-aside versus write-through, quelle politique d’éviction, quelle taille pour couvrir 80 % des lectures. L’évaluateur s’en fiche que tu couvres tout. Il veut voir que tu sais plonger quand il le faut.

Prendre du recul. Dernière étape, la plus sous-estimée. Identifie toi-même les failles. Où est le single point of failure ? Quel composant sature en premier ? Qu’est-ce que tu as sacrifié, et pourquoi ?

Un candidat qui critique sa propre architecture impressionne davantage qu’un candidat qui présente un schéma soi-disant parfait. Contre-intuitif, mais c’est ce qui montre ta maturité.

Les erreurs qui reviennent sans arrêt

Plonger dans les détails sans avoir cadré le périmètre. Résultat : dix minutes cramées à concevoir un truc qui répond pas au besoin. Irrécupérable.

Rester en surface aussi, c’est un classique. Des boîtes, des flèches, zéro profondeur technique. L’évaluateur doute — et il a raison.

Dernier piège : pas de compromis explicites. Chaque décision a un coût. Tu choisis la cohérence éventuelle ? Dis ce que tu gagnes en disponibilité et ce que tu perds en garantie de lecture. C’est ça, raisonner en ingénieur. Pas juste poser des composants sur un tableau.

Se préparer pour de vrai

Étudie 8 à 10 systèmes classiques en profondeur. Pas 50 en surface. News feed, messagerie instantanée, système de réservation, raccourcisseur d’URL. Pour chacun, déroule URDGE du début à la fin.

Dessine. Estime. Identifie les compromis. Puis simule l’entretien avec quelqu’un, chronomètre en main. Seul devant ton miroir, ça marche pas — il te faut les questions déstabilisantes. « Et si le trafic fait x10 ? » « Pourquoi pas une autre approche ? » C’est là que tu progresses.

Le system design, c’est pas un examen qu’on révise. C’est une compétence qu’on forge à force de pratique.

FAQ

Comment gérer le stress des 5 premières minutes ? Respire. Prends un marqueur, note le problème en haut du tableau, et commence par poser des questions. Le simple fait de parler — même pour clarifier des évidences — te donne le temps de structurer ta réflexion. L’évaluateur préfère ça au silence suivi d’un schéma précipité.

Faut-il connaître tous les composants d’infra par coeur ? Non. Comprends les trade-offs de 6 ou 7 briques fondamentales (load balancer, cache, message queue, base relationnelle, base NoSQL, CDN, stockage objet) et tu couvres 90 % des cas. Le reste, tu le découvres en creusant un système précis pendant ta préparation.

Combien de temps de préparation pour un dev avec 5+ ans d’expérience ? Compte 3 à 4 semaines à raison d’une heure par jour. Une semaine pour revoir les fondamentaux distribués, deux semaines pour traiter 8 systèmes avec URDGE, une dernière pour des simulations chronométrées. Ça suffit si tu bosses avec méthode.

Est-ce que le framework URDGE marche pour les entretiens staff/principal ? Oui, mais les attentes changent. À ces niveaux, on attend que tu challenges les contraintes du problème lui-même, que tu proposes des alternatives business, et que ta phase « Evaluate » soit beaucoup plus poussée — coût opérationnel, impact organisationnel, migration progressive.

Le system design n’est qu’un round. Pour un plan de préparation complet couvrant le coding, le comportemental et la logistique, lis comment préparer un entretien technique. Et quand tu es prêt à t’entraîner avec un template, utilise le template de réponse system design.

C’est parti ? Rejoindre l’accès anticipé →