Réussir un entretien de system design
L'entretien de conception système déroute par son ouverture. Une méthode en cinq étapes pour structurer sa réponse et montrer un vrai raisonnement d'ingénieur.
« Concevez un raccourcisseur d'URL. » « Comment feriez-vous le fil d'actualité d'Instagram ? » L'entretien de system design (conception de système) déroute par son ouverture : il n'y a pas de réponse unique, pas de « bonne » solution gravée dans le marbre. C'est justement le but. Les recruteurs ne cherchent pas la perfection ; ils veulent voir votre démarche : comment vous clarifiez un problème flou, faites des choix, et en assumez les compromis. Voici une méthode éprouvée en cinq temps, avec les concepts à maîtriser.
1. Clarifier les besoins (ne jamais foncer)
L'erreur n°1 est de se jeter sur une solution. Commencez par poser des questions : combien d'utilisateurs actifs ? quelles fonctionnalités sont vraiment demandées (le « scope ») ? le système est-il dominant en lecture ou en écriture ? quelles contraintes de latence ? Distinguez explicitement les besoins fonctionnels (ce que le système fait) des besoins non fonctionnels (latence, disponibilité, cohérence, coût). Cette phase montre votre maturité : un ingénieur senior cadre avant de construire.
2. Estimer les ordres de grandeur
Un calcul « au dos de l'enveloppe » dimensionne le problème : requêtes par seconde (QPS), volume de stockage par an, bande passante. Exemple : 100 millions d'utilisateurs actifs par jour, chacun faisant 10 actions → ~1 milliard d'événements/jour ≈ ~11 500 QPS en moyenne, avec des pics 2 à 3× plus élevés. On ne cherche pas la précision comptable mais l'ordre de grandeur, car il détermine tout le reste : une base peut-elle tenir seule, ou faut-il partitionner ?
3. Dessiner l'architecture de haut niveau
Posez les grands blocs et leurs liens : clients, load balancer, passerelle d'API, services applicatifs, bases de données, caches, files de messages, CDN. Puis faites circuler une requête à travers le schéma, du clic utilisateur jusqu'au stockage et retour, pour vérifier qu'il tient debout. Un diagramme clair vaut mille mots.
4. Approfondir les points sensibles
Vous n'aurez pas le temps de tout détailler : choisissez deux ou trois zones critiques et creusez. Les classiques :
- Partitionnement (sharding) — comment répartir les données quand elles ne tiennent plus sur une machine (par clé de hachage, par plage…).
- Mise en cache — où placer un cache (Redis) pour absorber la lecture, et comment gérer son invalidation (« l'un des deux vrais problèmes difficiles de l'informatique »).
- Réplication & cohérence — lectures sur répliques, cohérence forte vs éventuelle.
- Files de messages — découpler l'écriture des traitements lourds (Kafka, SQS).
5. Nommer les compromis (le cœur du sujet)
Il n'existe pas d'architecture « correcte » dans l'absolu, seulement des compromis adaptés à un contexte. Le théorème CAP le formalise : en cas de partition réseau (P), un système distribué doit arbitrer entre cohérence (C) et disponibilité (A). Une banque privilégiera la cohérence ; un fil social, la disponibilité. Énoncez explicitement vos arbitrages et leurs conséquences — c'est ce qui distingue un senior d'un junior.
Un bon design ne commence pas par une base de données, mais par de bonnes questions et une estimation grossière. Les compromis viennent ensuite, assumés.
L'état d'esprit
Pensez à voix haute, structurez votre propos, et traitez l'exercice comme une conversation de conception avec un futur collègue — pas comme un examen. Ce qu'on évalue n'est pas une réponse mémorisée, mais votre capacité à raisonner sous incertitude et à communiquer clairement.