30 Questions de System Design Posées chez les FAANG (Avec Pistes de Réponse)
Un truc que personne ne vous dit sur les entretiens system design chez les FAANG : les questions se répètent. Pas mot pour mot, mais les schémas sous-jacents tournent dans un ensemble étonnamment restreint. Le “Concevez YouTube” de Google et le “Concevez Instagram Reels” de Meta sont, au niveau architectural, le même problème déguisé.
J’ai compris ça à mes dépens — après avoir préparé une vingtaine de questions qui semblaient toutes uniques, pour réaliser que je dessinais systématiquement les trois ou quatre mêmes architectures de base. Les détails changent. La structure, non. Le jour où j’ai commencé à voir les patterns plutôt que les noms de produits, tout s’est débloqué.
Cette liste est le fruit de cette prise de conscience. Trente questions, classées par difficulté, chacune avec une brève explication de pourquoi elle est posée et une piste d’approche pour démarrer. Ce ne sont pas des solutions complètes — si vous cherchez une méthode structurée pour les traiter, consultez le framework URDGE pour les entretiens system design. Cette liste, c’est votre banque de problèmes.
Débutant (Questions 1-10)
C’est le palier d’échauffement. La plupart des candidats de niveau intermédiaire verront au moins une de ces questions. Elles testent les fondamentaux — patterns de lecture/écriture, cache, scaling de base, conception d’API. Ne vous laissez pas tromper par le mot “débutant” : une réponse superficielle ici mène quand même au refus.
1. Concevoir un raccourcisseur d’URL (type Bitly)
Pourquoi c’est posé : C’est le “Hello World” du system design. Ca teste votre compréhension du hashing, du stockage clé-valeur, des patterns d’accès en lecture intensive et de la conception d’API de base. Quasiment toutes les FAANG ont utilisé une variante de cette question.
Concepts clés : Stratégies de hashing (base62 vs troncature MD5), magasins clé-valeur, cache read-through, redirections 301 vs 302, gestion des collisions.
Piste d’approche : Commencez par le contrat d’API (créer une URL courte, rediriger). Estimez l’échelle — écritures par seconde, ratio lecture/écriture. Un magasin clé-valeur comme DynamoDB s’intègre naturellement. Ajoutez un cache Redis pour les URLs populaires, car le trafic suit une distribution de Pareto. Le point intéressant, c’est votre stratégie de génération de clés — discutez des compromis entre IDs auto-incrémentés avec encodage base62 et le hashing.
2. Concevoir un outil de collage (type Pastebin)
Pourquoi c’est posé : C’est un raccourcisseur d’URL avec une variante — maintenant vous stockez du contenu, pas juste des mappings. Ca teste votre réflexion sur le stockage objet, les limites de taille et l’expiration par TTL.
Concepts clés : Stockage objet (S3), séparation métadonnées/contenu, expiration TTL, contrôle d’accès (collages publics vs privés), rate limiting.
Piste d’approche : Séparez les métadonnées (titre, expiration, auteur) dans une base de données du contenu réel dans un stockage objet. Générez des clés uniques comme pour un raccourcisseur d’URL. Ajoutez un service de nettoyage qui expire les anciens collages. Le détail que la plupart des candidats oublient : que se passe-t-il quand un collage devient viral ? Le cache CDN pour les collages publics résout ça.
3. Concevoir un limiteur de débit (rate limiter)
Pourquoi c’est posé : C’est faussement simple et ça teste votre compréhension de la coordination distribuée. N’importe qui peut décrire le token bucket en théorie ; le défi, c’est de le faire fonctionner sur plusieurs serveurs applicatifs.
Concepts clés : Algorithmes token bucket vs fenêtre glissante, Redis pour l’état distribué, conditions de concurrence, limites par utilisateur vs par IP vs par endpoint.
Piste d’approche : Choisissez un algorithme précis — le token bucket est le plus facile à expliquer. Utilisez Redis avec des opérations atomiques (INCR + EXPIRE) pour stocker les compteurs. Discutez de l’emplacement du limiteur (API gateway vs middleware). La vraie profondeur vient des cas limites : qu’en est-il du rate limiting distribué sur plusieurs data centers ? Comment gérer les rafales de requêtes élégamment ?
4. Concevoir un magasin clé-valeur
Pourquoi c’est posé : Cette question sonde votre connaissance des mécanismes internes des bases de données. C’est fréquent chez Google et Amazon, où on attend de vous que vous compreniez ce qui se passe sous le capot, pas juste que vous utilisiez des services managés.
Concepts clés : Arbres LSM vs B-trees, write-ahead logs, compaction, réplication (leader-follower vs sans leader), hashing cohérent pour le partitionnement, compromis du théorème CAP.
Piste d’approche : Clarifiez les exigences d’abord — c’est optimisé pour la lecture ou l’écriture ? Pour un système orienté écriture, partez sur une approche LSM tree (memtable + SSTables + compaction). Pour les scénarios distribués, utilisez le hashing cohérent pour partitionner les données entre les noeuds. Discutez de la stratégie de réplication et de ce qui se passe lors d’une panne de noeud. La discussion sur les compromis (cohérence vs disponibilité) est là où les points se gagnent.
5. Concevoir un système de notifications
Pourquoi c’est posé : Ca touche plusieurs canaux de livraison (push, SMS, email) et teste votre capacité à concevoir des systèmes asynchrones fiables qui dégradent gracieusement.
Concepts clés : Files de messages, patterns de fan-out, garanties de livraison (au-moins-une-fois vs exactement-une-fois), gestion des préférences utilisateur, rate limiting par canal, retry avec backoff exponentiel.
Piste d’approche : Commencez par un service de notification qui accepte les requêtes et les route vers des workers spécifiques par canal via des files de messages (une file par canal). Utilisez un store de préférences pour que les utilisateurs contrôlent ce qu’ils reçoivent. La décision de conception clé est la fiabilité : comment garantir qu’une notification est délivrée au moins une fois sans spammer les utilisateurs ? Des clés d’idempotence et un journal de livraison résolvent ça.
6. Concevoir un générateur d’ID unique (distribué)
Pourquoi c’est posé : En apparence trivial, mais ça révèle si vous comprenez le coût de coordination dans les systèmes distribués. L’auto-incrément ne marche pas sur plusieurs serveurs, et cette question explore pourquoi.
Concepts clés : IDs Snowflake (timestamp + machine ID + séquence), compromis des UUID (stockage, triabilité), problèmes de synchronisation d’horloge, plages d’IDs pré-allouées.
Piste d’approche : L’approche Snowflake de Twitter est la réponse standard : des IDs de 64 bits composés d’un timestamp (41 bits), d’un ID machine (10 bits) et d’un numéro de séquence (12 bits). Ca donne des IDs uniques et triables sans coordination entre serveurs. Discutez du problème de dérive d’horloge et comment NTP aide sans le résoudre complètement. Comparez avec les UUID — plus volumineux, non triables, mais zéro coordination nécessaire.
7. Concevoir une file de tâches (type Celery ou SQS)
Pourquoi c’est posé : Ca teste votre compréhension du traitement asynchrone, fondamental dans tout système à grande échelle. Amazon pose régulièrement des variantes de cette question.
Concepts clés : Livraison au-moins-une-fois, timeout de visibilité, files de lettres mortes, files prioritaires, scaling des workers, défis du traitement exactement-une-fois.
Piste d’approche : Composants principaux : les producteurs poussent des tâches dans une file, les consommateurs tirent et traitent. Utilisez un timeout de visibilité — si un worker ne confirme pas dans les N secondes, la tâche redevient disponible. Ajoutez une file de lettres mortes pour les tâches qui échouent de manière répétée. La discussion intéressante porte sur les garanties d’ordre : le FIFO strict est coûteux à grande échelle, donc la plupart des systèmes offrent un ordre au mieux. Nommez ce compromis.
8. Concevoir un limiteur de débit API pour un service cloud
Pourquoi c’est posé : Ca étend le limiteur de débit basique à un contexte SaaS multi-tenant. Maintenant vous gérez différents niveaux de service, des quotas, et la logique métier autour du throttling différencié pour les clients payants.
Concepts clés : Limites de débit par palier, comptage distribué, gestion de quotas, dégradation gracieuse (réponses 429 avec headers Retry-After), analytics pour le suivi d’utilisation.
Piste d’approche : Superposez les limites : globales, par tenant, par endpoint. Stockez les compteurs dans Redis, indexés par ID tenant + endpoint + fenêtre temporelle. Utilisez des compteurs à fenêtre glissante pour un comportement plus lisse que les fenêtres fixes. La décision critique côté métier : que se passe-t-il quand un client premium atteint sa limite ? Mettre les requêtes en file d’attente brièvement plutôt que les rejeter ? C’est le genre de réflexion produit que les interviewers adorent.
9. Concevoir un CDN (réseau de diffusion de contenu)
Pourquoi c’est posé : Les CDN sont une infrastructure invisible que les candidats utilisent souvent sans comprendre. Cette question teste votre compréhension de la distribution géographique, des hiérarchies de cache et de l’invalidation de cache.
Concepts clés : Serveurs edge, origin pull vs push, hiérarchies de cache (edge, régional, origin shield), TTL et invalidation de cache, routage basé sur le DNS, hashing cohérent pour les noeuds de cache.
Piste d’approche : Commencez par le chemin de lecture : la requête utilisateur touche le DNS, est routée vers le serveur edge le plus proche. Un cache hit retourne immédiatement ; un cache miss tire depuis l’origine (possiblement via un palier régional pour réduire la charge sur l’origine). Discutez des stratégies d’invalidation — le TTL est simple mais peut servir du contenu périmé, les API de purge sont précises mais complexes. Le point avancé : comment gérer les cache stampedes quand un objet populaire expire simultanément sur tous les edges ?
10. Concevoir un crawler web (basique)
Pourquoi c’est posé : Le crawling est un problème classique de systèmes distribués. Ca requiert de la coordination, de la politesse (ne pas bombarder les sites), de la déduplication et la gestion du désordre du web réel.
Concepts clés : Stratégie de crawling BFS vs DFS, frontière d’URL, politiques de politesse (robots.txt, rate limiting par domaine), déduplication d’URL (filtres de Bloom), coordination distribuée des tâches.
Piste d’approche : La frontière d’URL est la structure de données centrale — une file prioritaire d’URLs à visiter avec des contraintes de politesse par domaine. Les workers tirent des URLs, récupèrent les pages, extraient les liens et poussent les nouvelles URLs. Utilisez des filtres de Bloom pour la déduplication (a-t-on déjà vu cette URL ?). Discutez du scaling : partitionnez la frontière par domaine pour que chaque worker gère un sous-ensemble. La subtilité, c’est la gestion des pièges — pagination infinie, URLs dynamiques, pièges à crawlers.
Intermédiaire (Questions 11-20)
Ces questions apparaissent dans les entretiens pour ingénieurs seniors. Elles impliquent plusieurs sous-systèmes en interaction, des exigences temps réel ou des défis de cohérence complexes. Vous devez démontrer une réflexion sur les compromis, pas juste un assemblage de composants.
11. Concevoir un système de messagerie (type WhatsApp ou Slack)
Pourquoi c’est posé : La messagerie temps réel combine des connexions persistantes, l’ordonnancement des messages, des garanties de livraison et la détection de présence. Meta et Amazon posent cette question fréquemment.
Concepts clés : WebSockets pour les connexions persistantes, ordonnancement des messages (numéros de séquence par conversation), accusés de lecture, service de présence (basé sur les heartbeats), stockage de messages (écriture intensive, ordonné par temps), fan-out de chat de groupe.
Piste d’approche : Chaque utilisateur maintient une connexion WebSocket vers un serveur de chat. Un gestionnaire de connexions suit quel serveur héberge chaque utilisateur. Pour les messages 1:1, routez directement via la carte de connexions. Pour le chat de groupe, distribuez à tous les serveurs des membres. Stockez les messages dans une base optimisée pour les séries temporelles (Cassandra fonctionne bien). La partie difficile : que se passe-t-il quand un utilisateur est hors ligne ? Mettez les messages en file et livrez à la reconnexion. Discutez des implications du chiffrement de bout en bout si on vous le demande.
12. Concevoir un fil d’actualité (type Facebook ou Twitter)
Pourquoi c’est posé : Le problème du fan-out est central dans les réseaux sociaux. Cette question teste votre capacité à raisonner sur les compromis push vs pull à très grande échelle.
Concepts clés : Fan-out-on-write vs fan-out-on-read, problème des célébrités (utilisateurs avec des millions d’abonnés), cache de timeline, algorithmes de classement, cohérence à terme.
Piste d’approche : Approche hybride : fan-out-on-write pour les utilisateurs normaux (pré-calculer et pousser vers les timelines des abonnés), fan-out-on-read pour les célébrités (récupérer et fusionner au moment de la lecture). Stockez les timelines dans des listes Redis, plafonnées à quelques centaines d’entrées. La couche de classement se situe entre la timeline brute et l’utilisateur — elle réordonne, déduplique et insère des publicités. Discutez de ce que signifie la “cohérence à terme” ici : le post de votre ami pourrait prendre quelques secondes à apparaître, et c’est acceptable.
13. Concevoir Instagram
Pourquoi c’est posé : C’est une plateforme sociale avec beaucoup de médias qui combine le stockage de contenu, la génération de fil d’actualité et les interactions temps réel. Ca teste votre capacité à gérer de gros objets binaires aux côtés de données structurées.
Concepts clés : Stockage images/vidéos et livraison CDN, génération de fil (similaire au fil d’actualité), services de likes/commentaires, algorithmes d’exploration/découverte, pipeline de traitement d’images (redimensionnement, filtre, vignette).
Piste d’approche : Séparez le chemin d’upload du chemin de lecture. Les uploads vont dans le stockage objet (S3), déclenchent un pipeline de traitement asynchrone (redimensionnement en plusieurs formats, génération de vignettes), puis mettent à jour les métadonnées en base. Les lectures sont servies depuis le CDN. Le fil est une variante du problème de fil d’actualité — fan-out-on-write pour la plupart des utilisateurs. La fonctionnalité Explorer ajoute une couche de recommandation basée sur les signaux d’engagement. Discutez de comment vous géreriez un utilisateur uploadant une image de 50 Mo sur une connexion mobile instable (uploads par morceaux, reprise).
14. Concevoir un système d’autocomplétion de recherche
Pourquoi c’est posé : C’est critique en latence (les résultats doivent apparaître pendant la frappe) et intensif en données (des milliards de requêtes). Google pose cette question pour des raisons évidentes.
Concepts clés : Structure de données trie, top-K des requêtes fréquentes, pré-calcul vs classement temps réel, pipeline de collecte de données, couche de personnalisation, service depuis la mémoire.
Piste d’approche : Pré-calculez les complétions les plus populaires en utilisant un trie où chaque noeud stocke les N suggestions les plus fréquentes. Servez depuis la mémoire pour une latence sous 10 ms. Un pipeline offline séparé traite les logs de recherche, agrège les fréquences et reconstruit le trie périodiquement. La subtilité : comment gérer les requêtes tendance qui explosent soudainement ? Une couche temps réel qui détecte les anomalies de fréquence et injecte les tendances dans l’ensemble pré-calculé.
15. Concevoir un crawler web à grande échelle (échelle Google)
Pourquoi c’est posé : Ca étend le crawler basique à des milliards de pages. Maintenant vous gérez la priorisation, la fraîcheur, la détection de contenu dupliqué et une coordination distribuée massive.
Concepts clés : Priorisation d’URL (informée par PageRank), fingerprinting de contenu (simhash pour la détection de quasi-doublons), planification de re-crawl basée sur la fréquence de changement, frontière de crawl distribuée, cache DNS, politesse à grande échelle.
Piste d’approche : Partitionnez l’espace d’URLs entre les noeuds crawlers par domaine. Chaque noeud maintient une file prioritaire locale. Un scheduler central assigne les domaines et gère les priorités globales. Utilisez simhash pour détecter le contenu quasi-identique (URLs différentes, même article). La fréquence de re-crawl doit être adaptative — les pages qui changent toutes les heures sont crawlées toutes les heures ; les pages statiques sont crawlées mensuellement. La discussion avancée : comment respecter la contrainte de politesse sans sous-utiliser votre flotte de crawlers ?
16. Concevoir un système de stockage de fichiers (type Google Drive ou Dropbox)
Pourquoi c’est posé : Ca teste la synchronisation temps réel, la résolution de conflits, le découpage de fichiers volumineux et le support hors ligne. C’est une question favorite chez Google et Meta.
Concepts clés : Découpage de fichiers et déduplication, protocoles de synchronisation (transformation opérationnelle ou CRDT pour les conflits), service de métadonnées, stockage par blocs, versioning, détection de changements côté client (watchers de système de fichiers).
Piste d’approche : Découpez les fichiers en morceaux de taille fixe et stockez-les par hash de contenu (permet la déduplication entre utilisateurs). Un service de métadonnées suit la structure des fichiers, les permissions et les mappings de morceaux. La sync utilise un canal de notification — quand un fichier change, le serveur notifie les clients connectés de tirer les morceaux mis à jour. Résolution de conflits : pour les éditions simultanées, gardez les deux versions et laissez l’utilisateur résoudre. L’insight de performance : ne synchronisez que les morceaux modifiés, pas les fichiers entiers. Un fichier de 1 Go avec un changement d’un octet devrait transférer un seul morceau, pas 1 Go.
17. Concevoir une plateforme de streaming vidéo (type YouTube ou Netflix)
Pourquoi c’est posé : La vidéo implique un stockage massif, des pipelines de transcodage, du streaming à débit adaptatif et une livraison mondiale. Ca teste votre réflexion système de bout en bout.
Concepts clés : Pipeline de transcodage vidéo (multiples résolutions/codecs), streaming à débit adaptatif (HLS/DASH), CDN pour la livraison, URLs pré-signées pour le contrôle d’accès, moteur de recommandation, comptage de vues à grande échelle.
Piste d’approche : Chemin d’upload : le client envoie la vidéo brute vers le stockage objet, ce qui déclenche un pipeline de transcodage produisant plusieurs variantes résolution/débit. Les métadonnées (titre, vignettes, formats) sont stockées en base. Lecture : le client demande un fichier manifest listant les qualités disponibles, puis sélectionne adaptivement les segments selon la bande passante. Les segments vidéo sont servis depuis le CDN. La décision de conception intéressante : comment compter les vues de manière fiable à l’échelle de YouTube ? Du traitement par lots avec déduplication, pas des compteurs temps réel.
18. Concevoir un service de VTC (type Uber ou Lyft)
Pourquoi c’est posé : Le matching de localisation temps réel, les requêtes géospatiales et la tarification dynamique créent un problème de conception riche. Fréquent chez Amazon et Google.
Concepts clés : Indexation géospatiale (geohash, cellules S2), suivi de localisation temps réel, algorithme de matching, estimation d’ETA, surge pricing, machine à états du trajet, communication conducteur/passager.
Piste d’approche : Les conducteurs rapportent continuellement leur position ; stockez les positions dans un index géospatial (grille geohash). Quand un passager fait une demande, interrogez les conducteurs proches via le geohash, classez par distance et ETA, et dispatchez. Un service de trajet gère la machine à états (demandé, matché, en route, en cours, terminé). Le sujet avancé : le surge pricing nécessite un ratio offre/demande temps réel par zone géographique. Discutez de comment éviter l’oscillation (les prix montent, les conducteurs affluent, les prix chutent, les conducteurs partent).
19. Concevoir un système de monitoring de métriques (type Datadog ou Prometheus)
Pourquoi c’est posé : Ca teste votre compréhension des données temporelles, du débit d’écriture élevé, de l’agrégation, de l’alerting et de l’efficacité de stockage.
Concepts clés : Bases de données de séries temporelles, write-ahead logs, downsampling pour les données anciennes, modèles de collecte push vs pull, pipelines d’agrégation, moteur de règles d’alerting, optimisation des requêtes de tableau de bord.
Piste d’approche : Des agents sur chaque hôte poussent les métriques vers un service de collecte, qui écrit dans une base de séries temporelles (partitionnement par nom de métrique + plage temporelle). Données récentes en pleine résolution ; données plus anciennes sous-échantillonnées (les moyennes à la minute deviennent des moyennes à l’heure). L’alerting évalue des règles contre les données récentes et déclenche des notifications. L’insight stockage : les données de séries temporelles se compressent extrêmement bien car les valeurs consécutives sont souvent similaires — utilisez l’encodage delta ou la compression gorilla.
20. Concevoir un éditeur de documents collaboratif (type Google Docs)
Pourquoi c’est posé : La collaboration temps réel est l’un des problèmes distribués les plus difficiles dans la tech grand public. Ca teste la résolution de conflits, les transformations opérationnelles et la sync temps réel.
Concepts clés : Transformation opérationnelle (OT) ou CRDTs, conscience des curseurs et de la présence, connexions WebSocket, versioning de documents, undo/redo en contexte collaboratif, contrôle d’accès.
Piste d’approche : Chaque client maintient une copie locale et envoie des opérations (insertion, suppression) au serveur. Le serveur utilise l’OT pour transformer les opérations concurrentes afin qu’elles convergent vers le même état. Les opérations transformées sont diffusées à tous les clients connectés. Stockez le journal des opérations pour l’undo/redo et l’historique des versions. Le compromis clé : l’OT est éprouvée mais complexe ; les CRDTs sont plus simples à raisonner mais peuvent avoir un overhead d’état plus important. Choisissez-en une et justifiez.
Avancé (Questions 21-30)
C’est le territoire staff/senior-staff. Ces questions impliquent une orchestration inter-systèmes, des exigences de cohérence complexes, une distribution à l’échelle mondiale ou une profondeur spécifique au domaine. Le crédit partiel est attendu — l’objectif est de voir jusqu’où votre raisonnement s’étend.
21. Concevoir une file de messages distribuée (type Kafka)
Pourquoi c’est posé : Ca teste une compréhension profonde des fondamentaux des systèmes distribués : réplication, ordonnancement, partitionnement, groupes de consommateurs et sémantique exactement-une-fois.
Concepts clés : Partitionnement par topic, groupes de consommateurs, gestion des offsets, réplication (ISR — in-sync replicas), compaction de logs, livraison exactement-une-fois (producteurs idempotents + écritures transactionnelles), transfert zero-copy.
Piste d’approche : Les topics sont découpés en partitions, chacune un journal en append-only stocké sur un broker. Les producteurs écrivent vers les leaders de partition ; les réplicas dans l’ensemble ISR répliquent de manière synchrone. Les consommateurs d’un groupe possèdent chacun un sous-ensemble de partitions (rééquilibré à l’arrivée/départ). Les offsets suivent la progression de la consommation. La discussion avancée : comment atteindre l’exactement-une-fois ? Des producteurs idempotents (numéros de séquence par partition) plus des écritures transactionnelles qui commitent atomiquement les offsets et les enregistrements de sortie.
22. Concevoir un cache distribué (type cluster Memcached/Redis)
Pourquoi c’est posé : Le cache semble simple jusqu’à ce que vous le distribuiez. Ca teste le hashing cohérent, les stratégies d’invalidation de cache, la protection contre les thundering herds et la gestion des clés chaudes.
Concepts clés : Hashing cohérent avec noeuds virtuels, patterns cache-aside vs read-through vs write-through, thundering herd (basé sur les verrous vs expiration anticipée probabiliste), réplication des clés chaudes, préchauffage de cache, politiques d’éviction.
Piste d’approche : Utilisez le hashing cohérent pour distribuer les clés entre les noeuds de cache avec des noeuds virtuels pour l’équilibre. Pour les lectures : pattern cache-aside (l’application vérifie le cache, se rabat sur la base, peuple le cache). Protection contre le thundering herd : quand une clé populaire expire, utilisez un verrou distribué pour qu’une seule requête la reconstruise pendant que les autres attendent. Clés chaudes : répliquez sur plusieurs noeuds et équilibrez la charge des lectures. Discutez du cauchemar de l’invalidation : quelle stratégie assure la cohérence du cache avec la base de données ?
23. Concevoir un système de paiement (type Stripe)
Pourquoi c’est posé : Les systèmes financiers exigent une correction extrême. Ca teste l’idempotence, le traitement exactement-une-fois, les transactions distribuées et l’auditabilité. Fréquent chez Amazon et dans les rôles adjacents à la fintech.
Concepts clés : Clés d’idempotence, transactions distribuées (pattern saga), comptabilité en partie double, conformité PCI, machine à états du paiement, livraison de webhooks, réconciliation, sûreté des retries.
Piste d’approche : Chaque requête de paiement porte une clé d’idempotence pour empêcher les doubles débits. Utilisez une machine à états : créé, en traitement, réussi, échoué. Le service de paiement coordonne entre la vérification du marchand, la détection de fraude et l’intégration du processeur de paiement via le pattern saga (chaque étape a une action compensatoire pour le rollback). La comptabilité en partie double assure que chaque débit a un crédit correspondant. Le sujet avancé : la réconciliation — comment détecter et résoudre les divergences entre vos enregistrements et ceux du processeur de paiement en fin de journée ?
24. Concevoir un moteur de recherche (type Google Search)
Pourquoi c’est posé : C’est le problème ultime de system design full-stack. Crawling, indexation, classement, service — chacun est un système en soi. Généralement posé chez Google et parfois chez Amazon.
Concepts clés : Index inversé, classement TF-IDF et BM25, PageRank, partitionnement d’index (par document vs par terme), analyse de requête, correction orthographique, génération d’extraits, service par paliers.
Piste d’approche : Trois sous-systèmes majeurs : crawl (collecter les pages), index (construire un index inversé mappant les termes aux documents avec positions et fréquences), service (analyser la requête, consulter l’index, classer les résultats). Partitionnez l’index par plages de documents entre serveurs ; scatter-gather au moment de la requête. Le classement combine la pertinence textuelle (BM25) avec l’analyse de liens (PageRank) et les signaux de fraîcheur. La profondeur intéressante : l’indexation par paliers — servez les résultats depuis un petit index “chaud” d’abord (pages populaires), ne consultez l’index complet que si nécessaire. Ca réduit drastiquement le coût de service.
25. Concevoir un système de réservation hôtel/vol (type Booking.com)
Pourquoi c’est posé : Les systèmes d’inventaire font face au problème de la double réservation, qui est un défi de cohérence distribuée. Ca implique aussi la recherche dans des espaces d’attributs complexes.
Concepts clés : Verrouillage d’inventaire (pessimiste vs optimiste), cohérence à terme pour la recherche vs cohérence forte pour la réservation, indexation de recherche avec filtres, moteur de tarification, stratégies de surbooking, intégration de paiement.
Piste d’approche : Séparez le chemin de recherche (lecture intensive, cohérence à terme, servi depuis Elasticsearch avec données dénormalisées) du chemin de réservation (cohérence forte, sérialisé via la base de données). Pour la réservation : verrouillage optimiste avec vérification de version — lisez la version actuelle de la chambre, tentez l’écriture, réessayez si quelqu’un d’autre a réservé d’abord. La subtilité métier : les hôtels surbookent intentionnellement d’un faible pourcentage, donc votre système doit supporter des seuils de surbooking configurables. Discutez de comment les résultats de recherche affichent “3 chambres restantes” sans être une garantie d’inventaire temps réel.
26. Concevoir un service de proximité (type Yelp ou Google Maps nearby)
Pourquoi c’est posé : La recherche géospatiale à grande échelle n’est pas triviale. Ca teste votre connaissance de l’indexation spatiale, du classement par distance plus pertinence, et de la gestion de rayons de requête variables.
Concepts clés : Indexation géospatiale (geohash, quadtree, géométrie S2), requêtes par rayon, classement (distance, note, pertinence), cache par région, expansion dynamique du rayon, pipeline d’ingestion de données commerciales.
Piste d’approche : Indexez les commerces par geohash — chaque commerce obtient un préfixe geohash basé sur sa localisation. Pour une requête “restaurants près de moi”, calculez le geohash de l’utilisateur et interrogez les cellules environnantes. Utilisez un quadtree pour les zones à densité variable (plus de granularité à Paris, moins en Lozère). Classez les résultats par un score pondéré de distance, note et pertinence. L’insight avancé : le geohash a des cas limites aux frontières de cellules — un restaurant à 50 mètres pourrait être dans une cellule différente. Interrogez les cellules voisines pour gérer ça.
27. Concevoir une base de données distribuée à l’échelle mondiale (type Spanner)
Pourquoi c’est posé : C’est la question de systèmes la plus profonde que vous puissiez recevoir. Ca teste votre compréhension des protocoles de consensus, de la synchronisation d’horloge et des limites fondamentales de l’informatique distribuée.
Concepts clés : Consensus Paxos/Raft, TrueTime (GPS + horloges atomiques pour une incertitude d’horloge bornée), transactions externalement cohérentes, gestion des shards, commit en deux phases entre shards, transactions en lecture seule à un timestamp.
Piste d’approche : Les données sont shardées entre les régions, chaque shard répliqué via Paxos pour la tolérance aux pannes. Au sein d’un shard, un leader gère les lectures et écritures. Les transactions cross-shard utilisent le commit en deux phases coordonné par un gestionnaire de transactions. L’insight révolutionnaire de Spanner : TrueTime fournit une incertitude d’horloge bornée, permettant des lectures externalement cohérentes sans coordination inter-régions en attendant la fin de la fenêtre d’incertitude. Discutez de pourquoi c’est important — ca permet des lectures globalement cohérentes sur n’importe quelle réplique.
28. Concevoir un classement temps réel pour un jeu
Pourquoi c’est posé : Ca semble simple mais implique le classement de millions de joueurs avec des mises à jour temps réel. Ca teste votre compréhension des structures de données triées à grande échelle et des patterns de requête.
Concepts clés : Sorted sets Redis, stratégies de partitionnement pour les classements globaux, classements approximatifs vs exacts, débit de mise à jour des scores, classements régionaux vs globaux, classements à fenêtre temporelle.
Piste d’approche : Les sorted sets Redis offrent des mises à jour en O(log N) et des requêtes de rang en O(log N) — parfait pour des classements jusqu’à des dizaines de millions d’entrées sur un seul noeud. Pour une plus grande échelle, partitionnez par plages de scores et maintenez un compteur par partition pour calculer le rang global. Les classements à fenêtre temporelle (quotidiens, hebdomadaires) nécessitent des sorted sets séparés avec un nettoyage basé sur le TTL. Le compromis intéressant : le classement global exact à plus de 100M de joueurs est coûteux — un rang approximatif (“top 1%”) serait-il acceptable pour les contextes non compétitifs ?
29. Concevoir un planificateur de tâches distribué (type Airflow à grande échelle)
Pourquoi c’est posé : L’orchestration de workflows implique l’exécution de DAGs, la gestion de dépendances, la récupération après panne et l’allocation de ressources. Fréquent chez Google et Amazon où les pipelines de données sont une infrastructure critique.
Concepts clés : Représentation de DAG, tri topologique pour l’ordre d’exécution, machine à états des tâches, verrouillage distribué pour l’assignation de tâches, détection de pannes par heartbeat, politiques de retry, support de backfill, gestion des pools de ressources.
Piste d’approche : Stockez les DAGs de workflow dans une base de données. Un service scheduler évalue les DAGs périodiquement : pour chacun, vérifie si les dépendances sont satisfaites et met en file les tâches prêtes dans une file de tâches distribuée. Les workers tirent les tâches, les exécutent et rapportent le statut. Utilisez des heartbeats pour détecter les workers bloqués et réassigner leurs tâches. La complexité : que se passe-t-il quand une tâche au milieu d’un DAG échoue ? Supportez des politiques configurables — réessayer N fois, sauter et continuer en aval, ou échouer le DAG entier. Discutez de comment gérer les backfills (réexécution d’exécutions historiques de DAG).
30. Concevoir un moteur d’appariement boursier
Pourquoi c’est posé : C’est probablement la question de system design la plus difficile. Elle exige une latence extrêmement basse, un ordonnancement déterministe et une correction sous haut débit. Posée dans les entretiens fintech de haut niveau.
Concepts clés : Carnet d’ordres (priorité prix-temps), algorithmes d’appariement (prix-temps, pro-rata), séquenceur pour l’ordonnancement déterministe, event sourcing, co-localisation pour la latence, diffusion de données de marché, coupe-circuits.
Piste d’approche : Le coeur est un moteur d’appariement mono-thread traitant les ordres séquentiellement depuis un séquenceur (l’ordonnancement déterministe est non négociable). Le carnet d’ordres maintient les côtés achat et vente triés par prix, puis par temps. Quand un ordre entrant correspond (prix d’achat >= prix de vente), exécutez la transaction et émettez des événements. L’event sourcing signifie que le journal des ordres EST la source de vérité ; l’état peut être reconstruit en le rejouant. Le défi de scaling : vous ne pouvez pas scaler horizontalement le moteur d’appariement pour un seul instrument car l’ordonnancement doit être déterministe. Scalez en shardant par instrument. Discutez de comment les données de marché (mises à jour de prix) sont diffusées à des millions d’abonnés avec une latence minimale.
Comment Pratiquer ces Questions Efficacement
Collecter des questions, c’est la partie facile. Ce qui sépare ceux qui décrochent une offre de ceux qui collectionnent les emails de refus, c’est la manière de s’entraîner.
Utilisez un framework, pas une page blanche. Si vous vous asseyez devant “Concevoir YouTube” et commencez juste à dessiner, vous allez passer dix minutes à fixer le tableau blanc. Utilisez une approche structurée — cadrez le problème, estimez l’échelle, définissez les APIs, puis architecturez. Si vous n’avez pas encore de framework, la méthode URDGE est un bon point de départ.
Chronométrez-vous. Les vrais entretiens durent 35-45 minutes. Entraînez-vous sous la même contrainte. Une solution élégante qui prend quatre-vingt-dix minutes ne vaut rien en contexte d’entretien.
Parlez à voix haute. Le system design est un exercice verbal. Vous n’écrivez pas du code ; vous narrez votre réflexion. Entraînez-vous à discuter des compromis, même si ça semble bizarre seul. Enregistrez-vous si vous supportez de vous réécouter ensuite.
Allez trois niveaux en profondeur sur les sujets clés. Ne vous contentez pas de savoir que Redis existe. Sachez quand vous choisiriez Redis plutôt que Memcached, quelles politiques d’éviction il supporte, et ce qui se passe pour votre cache pendant un failover. Trois niveaux de “pourquoi” sur n’importe quelle technologie couvriront la plupart des questions de suivi des interviewers.
Entraînez-vous en binôme. Trouvez un ami qui se prépare aussi et alternez les rôles. Le rôle d’interviewer vous apprend autant que celui de candidat — vous commencez à remarquer ce qui rend une réponse convaincante versus floue.
Et gardez une trace de vos réponses. Pour une structure à remplir réutilisable sur les trente questions, consultez notre template de réponse system design.
FAQ
Q : Les FAANG posent-elles vraiment ces questions exactes ?
La plupart, oui — ou des variantes proches. “Concevoir un système de chat” pourrait devenir “Concevoir Facebook Messenger” ou “Concevoir Slack”, mais le problème sous-jacent est identique. Les entreprises font tourner leurs banques de questions, mais les patterns sous-jacents sont stables depuis des années. Se préparer au pattern vous donne plus de couverture que mémoriser des questions spécifiques à une entreprise.
Q : Combien de ces questions devrais-je pratiquer avant de passer l’entretien ?
Huit à dix, réparties sur les trois niveaux de difficulté. L’objectif n’est pas d’avoir une réponse toute prête pour chaque question — c’est de développer une aisance avec les briques de base (cache, files, partitionnement, réplication) pour pouvoir les assembler à la volée. Après huit problèmes bien pratiqués, vous reconnaîtrez les patterns dans toute nouvelle question.
Q : Faut-il mémoriser des architectures ou comprendre les briques de base ?
Les briques de base, sans hésitation. Les architectures mémorisées s’effondrent sous les questions de suivi. Si vous comprenez vraiment le hashing cohérent, vous pouvez l’appliquer à un cache distribué, un CDN ou une stratégie de partitionnement — même si vous n’avez jamais vu la question spécifique. Les briques de base sont la compétence transférable ; les architectures ne sont que des assemblages.
Q : Quelle est la plus grosse erreur que font les candidats en entretien de system design ?
Foncer sur la solution. Ils entendent “Concevoir Uber” et commencent immédiatement à dessiner des microservices. Les meilleurs candidats passent les cinq à dix premières minutes à poser des questions, définir le périmètre et estimer l’échelle. Le temps qu’ils prennent le marqueur, ils savent exactement ce qu’ils construisent et pourquoi. Cet investissement initial fait gagner du temps et produit une conception focalisée et cohérente plutôt qu’un bazar tentaculaire.
Le system design n’est qu’une pièce du puzzle. Pour un plan de préparation complet couvrant les rounds de code, les entretiens comportementaux et la logistique, lisez comment préparer un entretien technique. Et quand vous êtes prêt à structurer vos réponses d’entraînement, consultez le template de réponse system design.
Fini de lire ? Rejoignez l’accès anticipé —>