Entretien de conception de systèmes : comment structurer votre réponse
Intention de recherche : Ingénieurs de niveau intermédiaire à senior qui maîtrisent les systèmes distribués mais bloquent quand on leur demande de les concevoir en live face à un recruteur.
Pourquoi de bons ingénieurs échouent aux entretiens de conception de systèmes
Vous avez construit des systèmes distribués. Vous avez déboggué des incidents en production. Vous savez ce qu'est un CDN. Et pourtant, quand on vous dit « Conçois Twitter », votre esprit se vide.
Le problème n'est pas la connaissance — c'est la structure. Les questions de conception de systèmes sont délibérément ouvertes. Sans cadre clair, vous sautez entre les composants, oubliez de clarifier les exigences et manquez de temps avant d'avoir couvert l'essentiel.
Les recruteurs ne notent pas votre diagramme final. Ils observent votre façon de penser : est-ce que vous recueillez les exigences, proposez une conception, identifiez les goulots d'étranglement et raisonnez sur les compromis ? C'est ce que l'entretien de conception de systèmes évalue vraiment.
Le cadre en 5 étapes pour tout entretien de conception de systèmes
Étape 1 : Clarifier les exigences (3–5 minutes)
Avant de dessiner quoi que ce soit, posez des questions. Ce n'est pas gagner du temps — c'est la partie la plus importante.
Exigences fonctionnelles — ce que le système doit faire :
- Quelles sont les actions principales des utilisateurs ? (publier, lire, chercher, suivre ?)
- Quels cas d'utilisation sont hors périmètre ?
Exigences non fonctionnelles — comment le système doit se comporter :
- Échelle : combien d'utilisateurs actifs quotidiens ? Lectures intensives ou écritures intensives ?
- Objectifs de latence : qu'est-ce qui est acceptable pour l'action principale de l'utilisateur ?
- Disponibilité : quel est le SLA de disponibilité ? Peut-on tolérer une brève interruption lors des déploiements ?
- Cohérence : cohérence forte requise, ou cohérence éventuelle suffisante ?
Notez les chiffres. « 1M d'utilisateurs quotidiens, ratio lecture/écriture 100:1, p99 < 200ms pour les lectures » — cela conditionne chaque décision architecturale.
Ne sautez pas cette étape même si l'énoncé semble clair. Les recruteurs laissent intentionnellement des ambiguïtés pour voir si vous poserez des questions.
Étape 2 : Estimer l'échelle (2–3 minutes)
Les calculs de back-of-the-envelope fondent votre conception. Pour un système à lectures intensives avec 10M d'utilisateurs actifs quotidiens :
- Supposez 50 lectures/jour par utilisateur → 500M lectures/jour → ~6 000 lectures/seconde
- Stockage : si chaque enregistrement fait 1 Ko et vous stockez 10M nouveaux enregistrements/jour → 10 Go/jour → 3,6 To/an
Ces chiffres vous indiquent si vous avez besoin d'une seule base de données ou du sharding, si un seul nœud de cache suffit, et à quoi doit ressembler votre stratégie CDN.
Étape 3 : Conception haut niveau (10–12 minutes)
Dessinez maintenant. Commencez par la conception la plus simple qui satisfait vos exigences. Une bonne conception haut niveau pour la plupart des systèmes comprend :
- Client → API Gateway → Services applicatifs
- Bases de données — quel type et pourquoi ? (relationnelle, NoSQL, séries temporelles)
- Cache — que mettez-vous en cache et pourquoi ?
- Traitement asynchrone — où une file de messages s'intègre-t-elle ?
- CDN — pour le contenu statique ou les lectures géographiquement distribuées
Par exemple, un raccourcisseur d'URL à l'échelle :
- Chemin d'écriture : Client → API → Serveur applicatif → BDD (écrit le mapping court:long) + Cache
- Chemin de lecture : Client → CDN → Répartiteur de charge → Serveur applicatif → Cache (Redis) → BDD en cas d'absence de cache
- Génération d'URL courte : Utilisez un ID basé sur un compteur avec encodage base-62 ou un générateur d'ID distribué (Snowflake)
Exprimez vos choix à voix haute : « J'utilise PostgreSQL ici car les données sont relationnelles et nous avons besoin d'une cohérence forte pour les écritures. Pour les lectures, je mettrai Redis en frontal. »
Étape 4 : Analyses approfondies (10–15 minutes)
Après la vue d'ensemble, le recruteur vous orientera généralement vers les domaines qui l'intéressent le plus. Thèmes courants :
- Conception du schéma de base de données — quelles sont vos tables, index, stratégie de sharding ?
- Stratégie de cache — cache-aside vs. write-through ? TTL ? Invalidation de cache ?
- Gestion des points chauds — que se passe-t-il quand les publications d'une célébrité reçoivent 10M de hits ?
- Cohérence vs. disponibilité — où faites-vous ce compromis explicitement ?
- Fan-out de données — pour les fils sociaux, comment propagez-vous les écritures aux abonnés ?
Approfondissez quand on vous le demande. Le recruteur veut vous voir aller au-delà de « mettre un cache devant la base de données » pour arriver à « voici la politique d'éviction, voici comment je gère les tempêtes de cache, voici le compromis que je fais. »
Étape 5 : Compromis et alternatives (5 minutes)
Concluez en reconnaissant ce que vous avez délibérément omis ou simplifié. C'est ce qui sépare les bons candidats des excellents.
« J'ai choisi la cohérence éventuelle ici pour obtenir un meilleur débit d'écriture — mais si le métier exigeait que chaque lecture reflète la dernière écriture, je devrais repenser cela avec une réplication synchrone, qui ajoute de la latence. »
Cela signale une maturité d'ingénieur : vous comprenez que chaque décision architecturale est un compromis, pas une bonne réponse.
Questions courantes de conception de systèmes et ce qu'elles testent vraiment
| Question | Ce qu'elles testent vraiment |
|---|---|
| Concevoir un raccourcisseur d'URL | Hachage, stockage, débit de lecture élevé, cache |
| Concevoir le fil Twitter/Instagram | Stratégies de fan-out, cohérence éventuelle, CDN |
| Concevoir un limiteur de débit | Token bucket vs. leaky bucket, compteurs distribués |
| Concevoir un système de notifications | Traitement asynchrone, files de messages, logique de réessai |
| Concevoir un cache distribué | Hachage consistant, réplication, politiques d'éviction |
Les plus grandes erreurs dans les entretiens de conception de systèmes
Sauter directement au code ou aux diagrammes. Commencez toujours par les exigences, même si le problème semble évident.
Concevoir le système parfait. Il n'existe pas de système parfait. Le recruteur veut un raisonnement sur les compromis, pas un diagramme de manuel scolaire.
Garder le silence. Narrez votre réflexion à voix haute. Si vous envisagez deux approches, dites-le. « Je choisis entre X et Y — X offre de meilleures performances en écriture mais Y est plus facile à mettre à l'échelle en lecture. Étant donné notre ratio de lecture 100:1, je vais avec Y. »
Ignorer l'échelle. Chaque décision doit se connecter à vos chiffres. « Ça fonctionne à 1K QPS, mais à 100K QPS il faudrait fragmenter — voici comment j'aborderais ça. »
Pratiquez maintenant
Connaître le cadre et l'appliquer en live sous pression de recruteur sont deux choses très différentes.