L'entretien system design est l'etape que la plupart des ingenieurs confirmes preparent mal. Ils apprennent par coeur une architecture de raccourcisseur d'URL, la recitent sous pression, et repartent avec un refus parce que l'examinateur evaluait tout autre chose. Ce qu'on mesure reellement, c'est votre facon de raisonner quand l'enonce est volontairement incomplet.
Ce que l'examinateur note vraiment
Personne n'attend une architecture de production en 45 minutes. La grille ressemble plutot a ceci :
- La structure du raisonnement. Savez-vous imposer un ordre a un enonce flou, a voix haute, pour que l'examinateur puisse vous suivre ?
- La clarification des besoins. Demandez-vous ce que le systeme doit faire avant de decider comment il le fait ?
- Les compromis explicites. Chaque choix a un cout. Le nommez-vous, ou presentez-vous vos decisions comme gratuites ?
- Savoir s'arreter. Continuez-vous a optimiser un composant qui n'est pas le goulot d'etranglement, ou passez-vous a la suite ?
Reciter une architecture memorisee vous dessert. Cela signale que vous ne saurez pas vous adapter quand l'examinateur changera une contrainte, ce qu'il fera.
Le budget de 45 minutes
La gestion du temps fait partie de la note, ce n'est pas un detail d'organisation. Une repartition qui fonctionne :
- 5 min : cadrage et clarification. Qui utilise le systeme, quelles sont les operations centrales, ce qui est explicitement hors perimetre.
- 5 min : estimation a la louche. Trafic, stockage, ratio lecture/ecriture.
- 10 min : architecture haut niveau. Des boites, des fleches, le flux de donnees. Rien de profond encore.
- 15 min : deep dive. L'examinateur choisit un ou deux composants. C'est la que se joue l'essentiel.
- 5-10 min : goulots d'etranglement, modes de panne, conclusion.
Annoncez ce plan des le depart. "Je vais passer environ cinq minutes sur les besoins, puis estimer, puis poser l'architecture generale, et ensuite approfondir ou vous voulez." Cette seule phrase demontre deja une structure.
Ecrivez les besoins avant tout le reste
C'est l'habitude au meilleur rendement de tout l'entretien, et c'est celle que la plupart des candidats sautent.
Coupez le tableau en deux :
Fonctionnel - ce que le systeme fait. "L'utilisateur televerse une video. D'autres la regardent. On peut chercher par titre." Trois a cinq points, pas plus.
Non fonctionnel - les proprietes qui contraignent la conception. Volume attendu, objectifs de latence, disponibilite, exigences de coherence, durabilite, profil lecture ou ecriture.
Les ecrire produit trois effets : l'examinateur vous corrige tot si vous avez mal lu l'enonce, vous disposez d'un point d'appui pour justifier chaque decision, et vous evitez de concevoir une fonctionnalite que personne n'a demandee. Ce sont les besoins non fonctionnels qui pilotent l'architecture. "Fortement coherent" et "coherent a terme" donnent deux systemes completement differents a partir du meme besoin fonctionnel.
Estimer sans faire semblant d'etre precis
Le calcul a la louche ne sert pas a tomber juste. Il sert a fixer un ordre de grandeur, pour savoir si vous avez besoin d'une base ou d'un cluster shard.
Deroulez :
- Le QPS. Utilisateurs actifs quotidiens multiplies par le nombre d'actions, divises par 86 400 secondes. Puis un facteur 2 a 3 pour la pointe.
- Le ratio lecture/ecriture. Un systeme a 100 lectures pour 1 ecriture justifie un cache agressif et des replicas de lecture. L'inverse non.
- La croissance du stockage. Taille moyenne d'un objet fois le nombre d'ecritures par jour fois la retention. Par jour, puis par an.
Enoncez chaque hypothese a voix haute : "Je pars sur 10 millions d'actifs quotidiens et environ 5 actions chacun, donc a peu pres 500 millions de requetes par jour, disons 6 000 QPS en moyenne et 15 000 en pointe." Si l'examinateur n'est pas d'accord avec le chiffre, il vous le dira, et corriger proprement est en soi un bon signal. Ne sortez jamais un chiffre en silence en le presentant comme un fait.
Les briques a vraiment comprendre
Il vous faut une connaissance operationnelle de ces elements, pas des schemas appris par coeur. Pour chacun : quel probleme il resout, et ce qu'il coute.
- Load balancing - L4 contre L7, health checks, sessions collantes et pourquoi elles compliquent la mise a l'echelle.
- Cache et invalidation - cache-aside contre write-through, strategie de TTL, et le fait que l'invalidation est la vraie difficulte.
- SQL contre NoSQL - on choisit selon le pattern d'acces, pas selon la mode. Transactions multi-entites et requetes libres : relationnel. Cle connue et gros volume d'ecriture : document ou wide-column.
- Sharding et cle de partition - le choix de la cle de partition est la conception. Une mauvaise cle donne des shards chauds et des requetes cross-shard.
- Replication et coherence - leader-follower, retard de replication, ce que voit l'utilisateur quand il relit sa propre ecriture.
- Files d'attente et traitement asynchrone - ce que vous decouplez, et les problemes de backpressure et d'ordre que vous heritez.
- CDN - deport du statique et du media, en-tetes de cache, delai d'invalidation.
- Rate limiting - token bucket, ou le placer, par utilisateur ou par IP.
- Idempotence - cles d'idempotence sur les ecritures, parce qu'a l'echelle les retries sont garantis.
Comment formuler un compromis
La formule qui marque des points est simple : choix, raison, cout.
"Je mets un cache Redis devant le service de profils parce que le ratio lecture/ecriture est de l'ordre de 100 pour 1. Le cout, ce sont des lectures perimees jusqu'a expiration du TTL, et un effet de troupeau au demarrage a froid si le cache tombe. Je limiterais ca avec du request coalescing."
A comparer avec "j'ajoute un cache pour les performances". Meme decision, moitie moins de points.
Quand vous ne savez pas
Vous allez rencontrer un trou pendant le deep dive. Le bon reflexe est de le dire, puis de raisonner.
"Je n'ai jamais implemente de consensus, donc je ne connais pas les details internes de Raft. Ce que je sais, c'est qu'il me faut un seul leader par partition et un moyen d'en elire un nouveau sans split-brain, donc un quorum. Raisonnons a partir de la."
Ca, on l'embauche. Le bluff assure, non, et il est demasque en une question de relance.
Un plan de preparation en 4 semaines en travaillant a plein temps
Semaine 1 - les fondamentaux. Deux heures par sujet sur la liste des briques. Redigez une demi-page pour chacune : ce qu'elle resout, ce qu'elle coute, quand ne pas l'utiliser.
Semaine 2 - lire de vrais systemes. Les blogs d'ingenierie d'entreprises qui operent a grande echelle. Concentrez-vous sur pourquoi elles ont change quelque chose, pas sur leur schema final.
Semaine 3 - s'entrainer a voix haute. Quatre a six exercices complets de 45 minutes, chronometres, parles, avec un outil de dessin ouvert. Enregistrez-vous. L'ecart entre penser une architecture et la narrer est plus grand qu'on ne l'imagine.
Semaine 4 - approfondir les trous. Reprenez les deux composants ou vous avez le plus bafouille et descendez d'un niveau. Faites deux simulations avec une vraie personne.
Entrainez-vous au tableau ou sur un outil de dessin partage des le premier jour. Dessiner en parlant est une competence distincte, et elle s'effondre si vous ne l'avez jamais pratiquee autrement que dans votre tete.
Les erreurs les plus frequentes
- Foncer sur un schema avant que quiconque se soit mis d'accord sur ce que fait le systeme.
- Reflechir en silence. Trente secondes de silence se lisent comme un blocage. Verbalisez.
- Sur-concevoir pour une echelle imaginaire. On ne shard pas pour 100 QPS.
- Ignorer le modele de donnees. Montrez les entites cles et les patterns d'acces principaux. Beaucoup de candidats n'ecrivent jamais une seule table.
- Aucune gestion des pannes. Que se passe-t-il quand ce noeud meurt, quand cette file s'accumule, quand cette dependance ralentit ?
Les variantes : frontend, data, ML
Le cadre reste le meme, les composants changent.
- Le system design frontend tourne autour de la strategie de rendu, la gestion d'etat, la livraison des bundles et des assets, le mode hors ligne, la conception du contrat d'API et l'accessibilite, pas du sharding de base de donnees.
- La data engineering se concentre sur batch contre streaming, l'evolution des schemas, les pipelines idempotents, les donnees en retard, les backfills et le cout par requete.
- Le ML system design ajoute les feature stores, le decalage entrainement/serving, le versioning et le rollback de modeles, l'evaluation en ligne contre hors ligne, et le budget de latence a l'inference.
Une note pour les profils seniors
A ce niveau, la connaissance des composants est presumee acquise. Ce qui separe les notes, c'est le cadrage et la priorisation : decider quoi laisser de cote, dire quelle partie du systeme porte le vrai risque, et choisir vous-meme le sujet du deep dive quand l'examinateur vous laisse la main. Si vous traitez tout avec la meme profondeur, vous ressemblez a quelqu'un qui n'a jamais eu a livrer sous contrainte de delai.
A retenir
- Ecrivez les besoins fonctionnels et non fonctionnels au tableau avant de dessiner quoi que ce soit. C'est l'habitude la plus rentable de l'entretien.
- Budgetez explicitement les 45 minutes et annoncez le plan a voix haute.
- Estimez a l'ordre de grandeur, enoncez vos hypotheses, et n'inventez jamais de precision.
- Nommez le cout de chaque choix. Une decision sans compromis annonce passe pour de la chance.
- Quand vous ne savez pas, dites-le et raisonnez depuis les principes de base. Le bluff se detecte immediatement.