Conception de systèmes
Explorez la performance des modeles IA en Conception de systèmes. Comparez classements, criteres de notation et benchmarks recents.
Vue d ensemble du genre
Compare la réflexion architecturale, l’analyse des compromis et la qualité de conception.
Dans ce genre, les capacites surtout observees sont Qualite de l architecture, Completude, Analyse des compromis.
Contrairement a coding, ce genre valorise davantage l architecture, l echelle, la fiabilite et les compromis que les details d implementation executable.
Un score eleve ici ne signifie pas que le modele ecrira le meilleur code fonctionnel ni l explication la plus simple.
Usages adaptes aux modeles forts dans ce genre
propositions d architecture, conception de services et discussions sur la scalabilite.
Ce que ce genre ne permet pas de juger a lui seul
la qualite d implementation bas niveau, la correction exacte ou l ecriture pour un public non technique.
Classement des modeles forts dans ce genre
Ce classement est trie par score moyen uniquement dans ce genre.
Derniere mise a jour: 25 Apr 2026 09:38
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
| Modeles classes | Detail | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.2 Retire | OpenAI |
100%
|
90
|
4 | 4 | Voir l evaluation et le score de GPT-5.2 |
| #2 | GPT-5.5 NOUVEAU | OpenAI |
100%
|
89
|
1 | 1 | Voir l evaluation et le score de GPT-5.5 |
| #3 | Claude Opus 4.6 Retire | Anthropic |
100%
|
88
|
4 | 4 | Voir l evaluation et le score de Claude Opus 4.6 |
| #4 | GPT-5.4 NOUVEAU | OpenAI |
75%
|
88
|
3 | 4 | Voir l evaluation et le score de GPT-5.4 |
| #5 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Voir l evaluation et le score de GPT-5 mini |
| #6 | Claude Sonnet 4.6 | Anthropic |
60%
|
85
|
3 | 5 | Voir l evaluation et le score de Claude Sonnet 4.6 |
| #7 | Claude Haiku 4.5 | Anthropic |
40%
|
82
|
2 | 5 | Voir l evaluation et le score de Claude Haiku 4.5 |
| #8 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Voir l evaluation et le score de Gemini 2.5 Pro | |
| #9 | Gemini 2.5 Flash |
0%
|
74
|
0 | 5 | Voir l evaluation et le score de Gemini 2.5 Flash | |
| #10 | Gemini 2.5 Flash-Lite |
0%
|
71
|
0 | 4 | Voir l evaluation et le score de Gemini 2.5 Flash-Lite |
Ce qui est evalue dans Conception de systèmes
Criteres et poids utilises pour ce classement par genre.
Qualite de l architecture
30.0%
Ce critere est present pour verifier Qualite de l architecture dans la reponse. Il a plus de poids parce que cet aspect influence fortement le resultat global de ce genre.
Completude
20.0%
Ce critere est present pour verifier Completude dans la reponse. Il garde un poids important parce qu il change visiblement la qualite, meme si ce n est pas le seul element qui compte.
Analyse des compromis
20.0%
Ce critere est present pour verifier Analyse des compromis dans la reponse. Il garde un poids important parce qu il change visiblement la qualite, meme si ce n est pas le seul element qui compte.
Scalabilite et fiabilite
20.0%
Ce critere est present pour verifier Scalabilite et fiabilite dans la reponse. Il garde un poids important parce qu il change visiblement la qualite, meme si ce n est pas le seul element qui compte.
Clarte
10.0%
Ce critere est present pour verifier Clarte dans la reponse. Il est plus legerement pondere parce qu il soutient l objectif principal sans definir a lui seul le genre.
Taches recentes
Conception de systèmes
Concevoir un service de notifications évolutif
Vous êtes ingénieur logiciel senior dans une entreprise de réseaux sociaux en forte croissance. Votre tâche est de concevoir un service de notifications évolutif et fiable. Ce service sera responsable de l'envoi de notifications aux utilisateurs concernant divers événements, tels que de nouveaux abonnés, des « j'aime » sur leurs publications, des commentaires et des messages directs.
Conception de systèmes
Concevoir un service de notification en temps réel
Présentez une conception système de haut niveau pour un service de notification en temps réel destiné à une plateforme de médias sociaux. Le service doit répondre aux exigences suivantes : - **Échelle :** 10 millions d’utilisateurs actifs quotidiens (DAU). - **Volume :** Chaque utilisateur reçoit en moyenne 20 notifications par jour. - **Latence :** Les notifications doivent être livrées à l’appareil de l’utilisateur en moins de 2 secondes. - **Canaux :** Prise en charge des notifications push (mobile), des e-mails et des notifications intégrées à l’application. - **Fiabilité :** 99,9 % de disponibilité et aucune perte de données de notification. Votre conception doit couvrir les aspects suivants : 1. **Architecture principale :** Décrivez les composants clés (par ex., API Gateway, Notification Service, Message Queue, Workers) et leurs interactions. 2. **Schéma de base de données :** Proposez un schéma de base de données de base pour stocker les notifications utilisateur et les préférences. 3. **Stratégie de mise à l’échelle :** Expliquez comment vous mettriez le système à l’échelle pour gérer la charge spécifiée et la croissance future. 4. **Fiabilité et tolérance aux pannes :** Détaillez les mesures que vous prendriez pour garantir une haute disponibilité et éviter toute perte de données. 5. **Principaux compromis :** Discutez d’au moins deux compromis significatifs réalisés dans votre conception (par ex., cohérence vs disponibilité, choix de la base de données, modèle push vs pull).
Conception de systèmes
Concevoir un service de raccourcissement d'URL
Concevez un service de raccourcissement d'URL (similaire à bit.ly ou tinyurl.com) qui doit respecter les contraintes suivantes : 1. Le service doit supporter 100 millions de nouvelles URL raccourcies par mois. 2. Le ratio moyen lecture/écriture est de 100:1 (c.-à-d. que les URLs raccourcies sont beaucoup plus souvent consultées qu'elles ne sont créées). 3. Les URLs raccourcies doivent rester accessibles pendant au moins 5 ans après leur création. 4. Le système doit atteindre une disponibilité (uptime) de 99,9 %. 5. La latence de redirection (du moment où la requête pour une URL courte est reçue jusqu'à l'émission de la redirection HTTP) doit être inférieure à 50 ms au 95e centile. Dans votre conception, traitez tous les points suivants : A. Architecture haut niveau : Décrivez les composants majeurs (serveurs d'API, bases de données, caches, équilibreurs de charge, etc.) et comment ils interagissent. Incluez une description claire du flux de requêtes pour la création d'URL et pour la redirection d'URL. B. Stratégie de génération d'URL courtes : Expliquez comment vous généreriez des codes courts uniques. Discutez les compromis entre différentes approches (p. ex. hachage, compteur, pool de clés pré-générées) et justifiez votre choix. C. Stockage des données : Choisissez une technologie de base de données et un schéma. Estimez les besoins de stockage sur 5 ans en tenant compte des contraintes. Expliquez pourquoi la base de données choisie est appropriée. D. Stratégie de montée en charge : Expliquez comment le système monte en charge pour gérer le trafic fortement orienté lecture. Discutez de la stratégie de cache, de l'approche de partitionnement/sharding de la base de données, et de la façon de traiter les "clés chaudes" (URLs virales qui reçoivent un trafic disproportionné). E. Fiabilité et tolérance aux pannes : Décrivez comment le système maintient une disponibilité de 99,9 %. Traitez ce qui se passe quand des composants individuels tombent en panne, et comment vous gérez la réplication des données et le basculement (failover). F. Principaux compromis : Identifiez au moins deux compromis de conception significatifs que vous avez faits et expliquez pourquoi vous avez choisi un côté plutôt qu'un autre au regard des contraintes données.
Conception de systèmes
Concevoir un service de raccourcissement d'URL
Concevez un service de raccourcissement d'URL (similaire à bit.ly ou tinyurl.com) qui doit gérer les contraintes suivantes : 1. Le service doit prendre en charge 100 millions de nouveaux raccourcissements d'URL par mois. 2. Le ratio des requêtes de lecture (redirection) aux requêtes d'écriture (raccourcissement) est de 100:1. 3. Les URLs raccourcies doivent être aussi courtes que possible mais doivent supporter le volume attendu pendant au moins 10 ans. 4. Le système doit atteindre 99,9 % de disponibilité (uptime). 5. La latence de redirection doit être inférieure à 50 ms au 95e centile. 6. Le service doit gérer une dégradation maîtrisée si un centre de données devient indisponible. Dans votre conception, abordez chacun des domaines suivants : A) API Design : Définissez les principaux points de terminaison API et leurs contrats. B) Data Model and Storage : Choisissez une solution de stockage, justifiez votre choix, expliquez votre schéma et estimez le stockage total nécessaire sur 10 ans. C) Short URL Generation : Décrivez votre algorithme pour générer les codes courts. Expliquez comment vous évitez les collisions et quel jeu de caractères et quelle longueur vous avez choisis, avec une justification mathématique montrant pourquoi l'espace de clés est suffisant. D) Scaling and Performance : Expliquez comment vous feriez évoluer les lectures et les écritures indépendamment. Décrivez votre stratégie de mise en cache, y compris la politique d'éviction et le taux de cache attendu. Expliquez comment vous atteignez l'exigence de latence de 50 ms p95. E) Reliability and Fault Tolerance : Décrivez comment le système gère les pannes de centres de données, la stratégie de réplication des données et quels compromis vous faites entre cohérence et disponibilité (référencez le théorème CAP). F) Trade-off Discussion : Identifiez au moins deux compromis de conception significatifs que vous avez faits et expliquez pourquoi vous avez choisi une option plutôt qu'une autre, y compris ce que vous sacrifiez et ce que vous gagnez. Présentez votre réponse comme un plan structuré avec des sections claires correspondant à A à F.
Conception de systèmes
Concevoir un service de raccourcissement d'URL
Concevez un service de raccourcissement d'URLs (similaire à bit.ly ou tinyurl.com) qui doit respecter les contraintes suivantes : 1. Le service doit prendre en charge 100 millions de nouveaux raccourcissements d'URL par mois. 2. Le ratio lecture/écriture est de 100:1 (c.-à-d. pour chaque URL créée, elle est consultée en moyenne 100 fois). 3. Les URLs raccourcies doivent rester accessibles pendant au moins 5 ans. 4. Le système doit atteindre une disponibilité de 99,9 %. 5. La latence de redirection (du moment de la réception d'une requête sur l'URL courte à l'émission de la redirection HTTP) doit être inférieure à 50 ms au 95e centile. Votre conception doit couvrir tous les domaines suivants : A. **Stratégie de génération d'URL courtes** : Comment générez-vous des codes courts, uniques et compacts ? Discutez du schéma d'encodage, de la longueur d'URL attendue et de la manière dont vous gérez les collisions ou l'épuisement de l'espace de clés. B. **Stockage des données** : Quelle(s) base(s) de données utiliserez-vous et pourquoi ? Estimez le stockage total nécessaire sur 5 ans. Expliquez votre conception de schéma et toute stratégie de partitionnement ou de sharding. C. **Architecture du chemin de lecture** : Comment servirez-vous les requêtes de redirection à grande échelle pour respecter les exigences de latence et de débit ? Discutez des couches de cache, de l'utilisation d'un CDN et de toute stratégie de réplication. D. **Architecture du chemin d'écriture** : Comment gérerez-vous l'ingestion de 100M de nouvelles URLs par mois de manière fiable ? Discutez de tout mécanisme de mise en file d'attente, de limitation de débit ou de considérations de cohérence. E. **Fiabilité et tolérance aux pannes** : Comment votre système gère-t-il les pannes de nœuds, les coupures de centre de données ou l'invalidation des caches ? Quelle est votre stratégie de sauvegarde et de récupération ? F. **Principaux compromis** : Identifiez au moins deux compromis importants dans votre conception (p. ex. cohérence vs disponibilité, coût de stockage vs performance de lecture, simplicité vs scalabilité) et expliquez pourquoi vous avez choisi l'option retenue. Présentez votre réponse sous forme de document de conception structuré avec des sections claires correspondant aux points A à F ci-dessus.
Conception de systèmes
Concevoir un service mondial de raccourcissement d’URL
Concevez un service public de raccourcissement d’URL similaire à Bitly. Les utilisateurs peuvent soumettre une URL longue et recevoir un alias court ; la visite du lien court doit rediriger rapidement vers l’URL d’origine. Le système doit prendre en charge des alias personnalisés, des dates d’expiration facultatives, des analyses de clics de base et l’atténuation des abus pour les liens malveillants. Exigences et contraintes : - Exigences fonctionnelles : - Créer des URL courtes pour des URL longues. - Rediriger les URL courtes vers les URL d’origine. - Prendre en charge des alias personnalisés lorsqu’ils sont disponibles. - Prendre en charge une durée d’expiration facultative par lien. - Enregistrer les événements de clic pour l’analytique. - Permettre aux utilisateurs de désactiver manuellement un lien. - Hypothèses d’échelle : - 120 millions de nouvelles URL courtes par mois. - 1,5 milliard de redirections par jour. - Le trafic de redirection est réparti à l’échelle mondiale et dominé par les lectures. - Les données analytiques doivent pouvoir être interrogées dans un délai de 15 minutes. - Objectifs de performance : - Latence p95 de redirection inférieure à 80 ms pour la plupart des régions. - p95 de création de lien court inférieure à 300 ms. - Disponibilité de 99,99 % pour les redirections. - Données et conservation : - Les liens peuvent vivre indéfiniment sauf s’ils expirent ou sont désactivés. - Les événements de clic bruts peuvent être conservés pendant 90 jours ; les analyses agrégées pendant 2 ans. - Contraintes opérationnelles : - Utilisez une infrastructure cloud standard ; ne supposez pas qu’un seul produit managé exotique résout tout. - Le budget compte : justifiez tous les choix de réplication, de mise en cache et de stockage. - Les codes courts doivent être compacts et raisonnablement difficiles à deviner à grande échelle, mais un secret parfait n’est pas requis. Dans votre réponse, fournissez : 1. Une architecture de haut niveau avec les principaux composants et le flux de données. 2. Des choix de stockage pour les métadonnées des liens, le chemin de redirection et les événements analytiques, avec justification. 3. Une stratégie de génération de codes courts, y compris la manière d’éviter les collisions et de gérer les alias personnalisés. 4. Un plan de montée en charge pour le trafic mondial, y compris la mise en cache, le partitionnement/sharding et les considérations multi-régions. 5. Un plan de fiabilité couvrant les pannes, les clés chaudes, la reprise après sinistre et le comportement en mode dégradé. 6. Les API clés et les principaux modèles de données. 7. Les considérations de sécurité et d’atténuation des abus. 8. Les principaux compromis que vous avez faits et pourquoi.