Questions d'entretien Conception système

Ce que couvrent les entretiens Conception système

Exemples de questions d'entretien Conception système

• Concevez un raccourcisseur d'URL comme bit.ly.
  Ce qu'une bonne réponse couvre

  • Hachage et base62 pour générer des identifiants courts
  • Stockage en base de données relationnelle ou NoSQL
  • Gestion des collisions et des redirections HTTP 301/302
  • Cache (Redis) pour les URL fréquentes
  • Considérations de scalabilité : partitionnement, réplication

  Voir un exemple de réponse

  Un raccourcisseur d'URL comme bit.ly doit générer un identifiant court unique à partir d'une URL longue et rediriger les requêtes vers l'URL d'origine. L'approche courante consiste à utiliser une base de données pour stocker la correspondance entre l'identifiant court et l'URL longue. L'identifiant peut être généré via un hachage (MD5, SHA-256) tronqué suivi d'un encodage base62 pour obtenir une chaîne de 6 à 8 caractères. Il faut gérer les collisions avec une table de hachage ou en réessayant. Les redirections doivent être des 301 pour le cache navigateur ou 302 pour les analytics. Un cache Redis en lecture permet de servir les URL populaires sans toucher la base. Pour monter en charge, on partitionne la table sur l'identifiant et on réplique la base. Un piège courant est de négliger l'attaque par génération séquentielle (devinette d'URL). La complexité en lecture est O(1) avec cache, O(log n) sans.

• Concevez un fil d'actualité (ex : timeline Twitter/Instagram).
  Ce qu'une bonne réponse couvre

  • Fan-out sur écriture vs lecture
  • Utilisation de cache pour les timelines pré-générées
  • Base de données clé-valeur pour les tweets/messages
  • Gestion du classement chronologique ou par pertinence
  • Scalabilité horizontale et réplication géographique

  Voir un exemple de réponse

  Un fil d'actualité (timeline) doit agréger les publications des abonnements d'un utilisateur. Deux approches principales : fan-out sur écriture (pré-calculer la timeline de chaque follower à chaque publication) et fan-out sur lecture (calculer la timeline à la demande). Pour un système comme Twitter, on utilise un hybride : les utilisateurs avec peu de followers reçoivent un fan-out sur écriture, ceux avec beaucoup (célébrités) utilisent un fan-out sur lecture pour éviter l'explosion d'écritures. Les timelines sont stockées dans un cache Redis sous forme de listes ordonnées par timestamp. Les tweets sont stockés dans une base NoSQL (Cassandra) pour la durabilité. Le classement est généralement chronologique inverse. Pour le passage à l'échelle, on partitionne les utilisateurs par ID et on réplique les caches. Les points chauds (célébrités) sont traités avec un cache dédié et des files d'attente asynchrones. Un piège est d'ignorer les limites de taille de timeline en mémoire.

• Concevez un limiteur de débit pour une API publique.
  Ce qu'une bonne réponse couvre

  • Algorithmes Token Bucket, Leaky Bucket, sliding window
  • Stockage des compteurs dans Redis (INCR, EXPIRE)
  • Décision au niveau du reverse proxy ou de l'API Gateway
  • Réponses HTTP 429 avec header Retry-After
  • Gestion des limites globales vs par utilisateur/IP

  Voir un exemple de réponse

  Un limiteur de débit pour une API publique doit contrôler le nombre de requêtes par fenêtre de temps. L'algorithme Token Bucket est populaire : un bucket avec un nombre de tokens se régénère à un taux constant, chaque requête consomme un token. On peut implémenter cela avec Redis en utilisant un compteur et un timestamp. Une autre approche est le sliding window log : stocker les timestamps des requêtes et compter ceux dans la fenêtre. Le choix dépend du compromis précision/performance. Le limiteur est placé au niveau du reverse proxy (NGINX, Envoy) ou de l'API Gateway. En cas de dépassement, on renvoie 429 Too Many Requests avec un header Retry-After. Il faut distinguer les limites globales (toutes les requêtes) et par utilisateur/IP. On peut utiliser des clés Redis comme 'rate_limit:{user_id}:{endpoint}'. Un piège courant est de ne pas bien gérer les conditions de course ; utiliser les commandes atomiques Redis (INCR, EXPIRE) ou Lua scripting.

• Concevez un système de chat prenant en charge les messages de groupe et les accusés de réception.
  Ce qu'une bonne réponse couvre

  • Architecture client-serveur avec WebSocket pour le temps réel
  • Base de données pour stocker les messages (ordre chronologique)
  • Gestion des accusés de réception (ACK) avec suivi par message
  • Support des messages de groupe via liste de participants
  • Scalabilité : partitionnement par chat_id, réplication

  Voir un exemple de réponse

  Un système de chat avec messages de groupe et accusés de réception nécessite une communication temps réel via WebSocket entre les clients et un service de chat. Chaque message est stocké dans une base de données (Cassandra ou PostgreSQL) avec un identifiant unique, le contenu, l'expéditeur, le timestamp et un tableau des participants. Pour les accusés de réception, chaque message possède un tableau de 'lu par' qui est mis à jour lorsque le destinataire affiche le message. Les WebSocket sont maintenues via un load balancer avec sticky sessions. Pour les groupes, une file d'attente (Kafka) distribue le message à tous les membres connectés. Les messages hors ligne sont stockés et délivrés à la reconnexion. Le partitionnement se fait sur l'ID du chat pour garantir l'ordre. Un piège est la scalabilité des accusés de réception pour les grands groupes ; on peut les accumuler et les envoyer par lots. L'ordre des messages doit être garanti par un timestamp côté serveur.

• Comment feriez-vous passer un service de 1 000 à 10 millions d'utilisateurs ?
  Ce qu'une bonne réponse couvre

  • Optimisation de la base de données : index, mise en cache
  • Passage à une architecture distribuée (microservices)
  • Utilisation de CDN pour le contenu statique
  • Réplication des bases de données et sharding
  • Monitoring et auto-scaling (Kubernetes)

  Voir un exemple de réponse

  Passer de 1 000 à 10 millions d'utilisateurs nécessite une évolution progressive. À 1 000 utilisateurs, un serveur unique avec base de données (MySQL) et cache (Redis) suffit. Pour monter, on commence par optimiser les requêtes SQL, ajouter des index, et mettre en cache les données fréquentes (pages, sessions). Ensuite, on sépare le serveur web de la base de données. On introduit un CDN pour le contenu statique (images, CSS). À quelques milliers, on passe à une architecture de microservices : API, auth, notification, etc. On réplique la base en lecture (read replicas) et on sharde les données sur plusieurs nœuds. On utilise un load balancer (HAProxy, Nginx) et on déploie dans des conteneurs avec orchestration (Kubernetes) pour l'auto-scaling. Le monitoring (Prometheus, Grafana) est crucial pour détecter les goulets d'étranglement. La complexité la plus grande est le sharding de la base : choisir une clé de partitionnement (user_id) et gérer les requêtes cross-shard. Un piège est de procrastiner la migration vers le sharding ; il faut la planifier tôt.

• Concevez un magasin clé-valeur distribué avec haute disponibilité.
  Ce qu'une bonne réponse couvre

  • Consistance éventuelle (Eventual Consistency) pour la haute disponibilité
  • Algorithme de consensus Raft ou Paxos pour la coordination
  • Partitionnement (sharding) et réplication
  • Modèle de données clé-valeur (Dynamo, Cassandra)
  • Gestion des conflits : horloges vectorielles, derniere écriture gagnante

  Voir un exemple de réponse

  Un magasin clé-valeur distribué haute disponibilité privilégie la disponibilité sur la consistance forte. On s'inspire de DynamoDB ou Cassandra. Les données sont partitionnées (sharding) par hash de la clé sur un anneau (consistent hashing). Chaque donnée est répliquée sur N nœuds (facteur de réplication). Pour la haute disponibilité, on utilise un modèle de consistance éventuelle : les lectures et écritures peuvent se faire sur n'importe quel réplica, avec des horloges vectorielles pour détecter les conflits. La résolution des conflits se fait par 'dernière écriture gagnante' (LWW) ou par logique applicative. Pour la coordination, on peut utiliser Raft pour l'élection du leader dans chaque partition. Les opérations de lecture/écriture sont configurées avec des quorums (ex: W=2, R=2 pour N=3). On stocke les données dans une structure clé-valeur persistante (LSM-tree). Un piège est de négliger le gossip protocol pour la détection de pannes. La complexité temporelle des opérations est généralement O(log n) pour la recherche sur l'anneau.

Comment se préparer

• Commencez toujours par clarifier les exigences et les contraintes — ne sautez pas directement à une solution.
• Utilisez un cadre reproductible : exigences → estimation → API → modèle de données → passage à l'échelle → compromis.
• Explicitez les compromis (ex : cohérence vs disponibilité) ; il y a rarement une seule bonne réponse.
• Dirigez la conversation et gérez le temps — couvrez d'abord les aspects généraux, puis approfondissez là où on vous le demande.

Questions fréquemment posées