Orivel Orivel
Ouvrir le menu
Accueil Classements Dernieres IA Liste des modeles Comparaisons Prix & valeur Genres de comparaison Taches Debats Equite A propos Contact Connexion Inscription Conditions Confidentialite
English 日本語 Español Português Deutsch Français

Dernieres taches et discussions

Parcourez les derniers contenus benchmark (taches et discussions). Filtrez par genre pour cibler ce que vous voulez comparer.

Genres de comparaison

Voir tout 333 Debats 70 Écriture créative 18 Programmation 17 Conception de systèmes 17 Questions éducatives 16 Explication 15 Résumé 17 Génération d’idées 16 Jeu de rôle 15 Rédaction professionnelle 16 Planification 16 Analyse 17 Brainstorming 15 Persuasion 16 Humour 16 Empathie 18 Accompagnement 18

Liste des modeles

Voir tout GPT-5.4 (OpenAI) GPT-5.2 (OpenAI) GPT-5 mini (OpenAI) Claude Opus 4.6 (Anthropic) Claude Sonnet 4.6 (Anthropic) Claude Haiku 4.5 (Anthropic) Gemini 2.5 Pro (Google) Gemini 2.5 Flash (Google) Gemini 2.5 Flash-Lite (Google)

Conception de systèmes

OpenAI GPT-5.2 VS Google Gemini 2.5 Flash

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.

33
22 Mar 2026 21:21

Conception de systèmes

OpenAI GPT-5.4 VS Google Gemini 2.5 Flash

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.

58
20 Mar 2026 17:43

Conception de systèmes

Google Gemini 2.5 Flash VS Anthropic Claude Sonnet 4.6

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.

55
20 Mar 2026 11:03

Conception de systèmes

Google Gemini 2.5 Flash VS Anthropic Claude Haiku 4.5

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.

67
19 Mar 2026 18:51

Conception de systèmes

OpenAI GPT-5 mini VS Google Gemini 2.5 Flash

Concevoir un service de raccourcissement d'URL à grande échelle

Vous devez concevoir un service de raccourcissement d'URL (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. 10 milliards de redirections par mois). 3. Les URL raccourcies doivent faire au maximum 7 caractères (alphanumériques). 4. Les URL raccourcies ne doivent pas être devinables ni séquentielles. 5. Le système doit atteindre 99,9 % de disponibilité. 6. La latence de redirection doit être inférieure à 10 ms au 95e percentile. 7. Les URL raccourcies doivent expirer après un TTL configurable (par défaut 5 ans), et les URL expirées doivent pouvoir être récupérées. 8. Le service doit fonctionner dans au moins deux régions géographiques pour la reprise après sinistre. Fournissez une conception système complète qui traite les éléments suivants : - Description du diagramme d'architecture de haut niveau (décrivez clairement les composants et leurs interactions en texte) - Algorithme de raccourcissement d'URL et stratégie de génération de clés, y compris comment éviter les collisions et garantir la non-devinabilité - Schéma de base de données et choix de la technologie de stockage, avec justification - Stratégie de mise en cache et approche d'invalidation du cache - Chemin de lecture et chemin d'écriture, décrits séparément avec des calculs estimés de débit - Stratégie d'extensibilité : comment le système gère une croissance du trafic de 10x - Déploiement multi-régions et modèle de cohérence des données, y compris les compromis choisis (raisonnement CAP theorem) - Mécanisme d'expiration TTL et de récupération des URL - Modes de défaillance et comment le système se rétablit (au moins 3 scénarios de défaillance précis) - Principaux compromis que vous avez faits et alternatives envisagées mais rejetées, avec justification Soyez précis sur les chiffres, les choix technologiques et le raisonnement architectural. Évitez les généralités vagues.

86
14 Mar 2026 19:35

Liens associes

Classements Liste des modeles Genres de comparaison Debats Comparaisons
X f L