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: 22 Mar 2026 21:21
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 | OpenAI |
100%
|
90
|
3 | 3 | Voir l evaluation et le score de GPT-5.2 |
| #2 | GPT-5.4 | OpenAI |
100%
|
89
|
3 | 3 | Voir l evaluation et le score de GPT-5.4 |
| #3 | Claude Opus 4.6 | Anthropic |
100%
|
87
|
3 | 3 | Voir l evaluation et le score de Claude Opus 4.6 |
| #4 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Voir l evaluation et le score de GPT-5 mini |
| #5 | Claude Sonnet 4.6 | Anthropic |
60%
|
85
|
3 | 5 | Voir l evaluation et le score de Claude Sonnet 4.6 |
| #6 | Claude Haiku 4.5 | Anthropic |
50%
|
84
|
2 | 4 | Voir l evaluation et le score de Claude Haiku 4.5 |
| #7 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Voir l evaluation et le score de Gemini 2.5 Pro | |
| #8 | Gemini 2.5 Flash |
0%
|
74
|
0 | 5 | Voir l evaluation et le score de Gemini 2.5 Flash | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | 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 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.
Conception de systèmes
Concevoir un service mondial de raccourcissement d'URL
Concevez un service de raccourcissement d'URL disponible globalement, similaire à Bitly. Le service doit permettre aux utilisateurs de créer des liens courts qui redirigent vers des URL longues, prendre en charge des alias personnalisés pour les utilisateurs payants, suivre l'analytique des clics, et permettre aux liens d'expirer à un moment spécifié. Exigences : - Gérer 120 millions de nouveaux liens courts par jour. - Gérer 4 milliards de redirections par jour. - Le trafic de pointe peut atteindre 3 fois la moyenne quotidienne. - Objectif de latence pour les redirections : p95 < 80 ms pour les utilisateurs en Amérique du Nord, en Europe et en Asie. - Objectif de latence pour la création de liens courts : p95 < 300 ms. - Objectif de disponibilité du service : 99,99 % pour les redirections. - Les données analytiques peuvent être finalement cohérentes dans un délai de 5 minutes. - Les alias personnalisés doivent être uniques au niveau mondial. - Les liens expirés ou supprimés doivent cesser de rediriger rapidement. - Le système doit tolérer des pannes régionales sans interruption totale du service. Hypothèses que vous pouvez utiliser : - La longueur moyenne d'une URL longue est de 500 octets. - Les événements analytiques incluent horodatage, ID du lien, pays, type d'appareil et domaine du référent. - Le trafic de lecture est bien supérieur au trafic d'écriture. - Vous pouvez choisir des technologies SQL, NoSQL, cache, stream, CDN et de messagerie selon les besoins, mais justifiez-les. Dans votre réponse, fournissez : 1. Une architecture de haut niveau avec les composants principaux et les flux de requêtes. 2. Le modèle de données et les choix de stockage pour les liens, les alias et l'analytique. 3. Une stratégie de montée en charge pour un trafic à dominance lecture, incluant la mise en cache et le routage régional. 4. Une stratégie de fiabilité couvrant le basculement, les décisions de cohérence et la gestion des pannes régionales. 5. Les principaux compromis, goulets d'étranglement, et au moins trois risques avec leurs mesures d'atténuation. 6. Une brève estimation de capacité pour le stockage et le débit en utilisant les chiffres ci-dessus.
Conception de systèmes
Concevoir un service global de raccourcissement d'URL
Concevez un service public de raccourcissement d'URL similaire à Bitly. Le service doit permettre aux utilisateurs de créer des liens courts pour des URL longues, de spécifier éventuellement un alias personnalisé si disponible, et de rediriger les utilisateurs qui visitent le lien court vers la destination originale. Inclure une fonctionnalité d'analytics basique qui rapporte le nombre total de clics par lien et les clics par jour pour les 30 derniers jours. Supposez les contraintes suivantes : - 120 million new short links are created per month. - 1.2 billion redirect requests are served per month. - Read traffic is highly bursty, especially for viral links. - The service is used globally and users expect low-latency redirects. - Short links should remain valid for at least 5 years. - Redirect availability target is 99.99 percent. - Analytics may be eventually consistent by up to 10 minutes. - The system should prevent obvious abuse at a basic level, but a full trust and safety platform is out of scope. Dans votre conception, couvrez : - Architecture haute niveau et composants principaux. - Modèle de données et choix de stockage pour les mappages de liens et les analytics. - Stratégie de génération d'ID ou de jetons, y compris la gestion des alias personnalisés. - Conception de l'API pour créer des liens, effectuer des redirections et récupérer les analytics. - Stratégie de mise en cache, partitionnement et réplication. - Approche de fiabilité, y compris gestion des pannes et considérations multi-région. - Comment vous scalerez pour un trafic majoritairement en lecture et les points chauds viraux. - Principaux compromis en matière de cohérence, coût, latence et complexité opérationnelle. Indiquez toutes les hypothèses raisonnables que vous faites et justifiez vos choix.
Conception de systèmes
Concevoir une plateforme d'appariement de trajets en temps réel
Concevez l'architecture backend d'une plateforme de VTC qui met en relation des passagers et des chauffeurs à proximité en temps réel dans plusieurs villes. Votre conception doit prendre en charge ces exigences produit : - Les passagers peuvent demander une course en envoyant les lieux de prise en charge et de destination. - Les chauffeurs disponibles à proximité doivent recevoir la demande rapidement, et un seul chauffeur peut l'accepter. - Le système doit empêcher la double réservation des chauffeurs. - Les passagers et les chauffeurs doivent voir des mises à jour de statut de course en direct telles que demandé, accepté, arrivé, en cours et terminé. - La plateforme doit fournir un tarif estimé et un temps d'arrivée estimé avant confirmation. - L'historique des courses doit être disponible aussi bien pour les passagers que pour les chauffeurs. Contraintes et hypothèses : - 8 millions de demandes de course par jour. - La charge de pointe est 25 fois le taux moyen de demandes durant les fenêtres de déplacement. - Opère dans 40 villes, avec une répartition inégale du trafic. - Les mises à jour de localisation des chauffeurs actifs arrivent toutes les 3 secondes. - La latence acceptable côté passager pour l'appariement initial des chauffeurs est inférieure à 2 secondes au p95. - Les mises à jour de statut de course doivent généralement apparaître en moins de 1 seconde. - Le système doit rester disponible lors d'une panne de service régionale affectant un centre de données. - Les détails exacts du traitement des paiements sont hors du champ, mais les enregistrements de course doivent être durables pour la facturation ultérieure. - Les préoccupations de confidentialité, de sécurité et de conformité réglementaire peuvent être mentionnées brièvement, mais le principal focus est l'architecture et la montée en charge. Dans votre réponse, décrivez : - Les principaux services ou composants et leurs responsabilités. - Le flux de données depuis la demande de course jusqu'à l'affectation du chauffeur puis la complétion de la course. - Comment vous stockeriez et interrogeriez efficacement les localisations des chauffeurs. - Comment vous géreriez la montée en charge pour le trafic de pointe et les villes à fort trafic. - Comment vous assureriez la fiabilité, la tolérance aux pannes et la cohérence des données là où cela importe. - Les compromis clés de votre conception, y compris les endroits où vous préférez la cohérence éventuelle plutôt que la cohérence forte, ou vice versa. Vous n'avez pas besoin de fournir des produits cloud exacts. Une architecture claire et une conception axée sur le raisonnement sont préférées à un niveau d'implémentation exhaustif.