Orivel Orivel
Ouvrir le menu

Dernières tâches et discussions

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

Genres de comparaison

Liste des modeles

Conception de systèmes

Anthropic Claude Opus 4.7 VS Google Gemini 2.5 Flash

Concevoir un système évolutif de réservation de billets de concert

Concevez un système pour une plateforme de billetterie de concerts en ligne. Les utilisateurs peuvent parcourir les événements, voir la disponibilité des sièges, réserver des sièges spécifiques pendant 10 minutes, payer via un fournisseur de paiement externe et recevoir un billet numérique. La plateforme fonctionne dans une seule région cloud répartie sur plusieurs zones de disponibilité. Contraintes explicites : 3 millions d'utilisateurs enregistrés, 500 000 utilisateurs actifs quotidiens, les événements majeurs en mise en vente peuvent atteindre 150 000 utilisateurs simultanés, la charge de pointe est de 8 000 tentatives de réservation de sièges par seconde et 2 000 tentatives de paiement par seconde, chaque événement comporte jusqu'à 60 000 sièges, le système ne doit jamais vendre deux fois le même siège, les réservations de sièges expirent après 10 minutes si non payées, la latence p95 pour la navigation et les lectures de plans de salle doit être inférieure à 300 ms, la latence p95 pour la confirmation de réservation doit être inférieure à 800 ms hors temps du fournisseur de paiement, l'objectif de disponibilité pendant les fenêtres de mise en vente est de 99,95 %, l'objectif de point de récupération (RPO) est inférieur à 1 minute, l'objectif de temps de récupération (RTO) est inférieur à 15 minutes, et les callbacks du fournisseur de paiement sont au moins une fois, peuvent arriver dans le désordre et peuvent être retardés jusqu'à 5 minutes. Fournissez un plan de conception. Incluez les principaux services et magasins de données, les API principales, le modèle de données pour les sièges et les réservations, le flux des requêtes pour la navigation, la réservation, le paiement et l'expiration des réservations, la stratégie d'échelle pour les pics de trafic, l'approche de fiabilité et de reprise après sinistre, les choix de cohérence qui empêchent la survente, la surveillance et les alertes, ainsi que les principaux compromis ou alternatives que vous avez envisagés. Indiquez toutes les hypothèses raisonnables que vous faites.

174
19 May 2026 09:49

Analyse

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

Choix d'une base de données pour une startup SaaS en croissance

Vous conseillez le CTO d'une startup B2B SaaS âgée de deux ans qui fournit un logiciel de gestion de projet à des entreprises de taille moyenne. La configuration actuelle utilise une seule instance PostgreSQL, et elle montre maintenant des signes de tension : les requêtes en lecture sur les tableaux de bord prennent 3–8 secondes pendant les heures de pointe, la base de données fait 800 GB et croît d'environ ~40 GB/mois, et l'équipe prévoit que le nombre d'utilisateurs va tripler au cours des 12 prochains mois. L'équipe d'ingénierie compte 9 développeurs, dont un seul a une expérience significative en administration de bases de données. Le budget est contraint mais pas sévèrement limité. Le CTO envisage quatre options : 1. Monter en vertical l'instance PostgreSQL existante et ajouter des réplica en lecture. 2. Migrer vers une base de données SQL distribuée gérée (p. ex., CockroachDB ou un service de type Spanner). 3. Scinder la charge : conserver PostgreSQL pour les données transactionnelles et introduire un magasin analytique séparé (p. ex., ClickHouse ou BigQuery) pour les tableaux de bord. 4. Migrer vers une base de données de documents NoSQL (p. ex., MongoDB ou DynamoDB). Rédigez une analyse (environ 500–800 mots) qui : - Évalue chacune des quatre options au regard des contraintes spécifiques de la startup (lieu du goulot d'étranglement de performance, expertise de l'équipe, trajectoire de croissance, budget). - Identifie les compromis et risques clés de chaque option. - Parvient à une recommandation claire et justifiée (vous pouvez recommander une option unique ou une combinaison en phases). - Précise quelles preuves ou mesures vous voudriez vérifier avant de vous engager sur la recommandation. Soyez concret : faites référence aux chiffres fournis et évitez des conseils génériques sur les bases de données qui ignoreraient le scénario.

210
16 May 2026 09:38

Programmation

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

Limiteur de débit avec fenêtre glissante et tolérance de rafale

Concevez et implémentez un limiteur de débit sûr pour les threads dans un langage de votre choix (Python, Go, Java, TypeScript ou Rust) qui prend en charge les exigences suivantes : 1. **Surface de l'API** : Exposez au moins ces opérations : - `allow(client_id: str, cost: int = 1) -> bool` — retourne si la requête est autorisée immédiatement. - `retry_after(client_id: str) -> float` — retourne le nombre de secondes avant qu'au moins 1 unité de capacité soit disponible (0 si autorisé actuellement). - Un constructeur qui accepte une configuration par client : `rate` (unités par seconde), `burst` (unités max stockées), et un `window_seconds` optionnel pour la comptabilité par fenêtre glissante. 2. **Algorithme** : Implémentez un hybride qui combine un **token bucket** (pour la tolérance aux rafales) avec un **journal de fenêtre glissante ou un compteur** (pour borner le total des requêtes permises dans `window_seconds`, évitant les abus soutenus qu’un simple token bucket permettrait après recharges). Une requête n’est autorisée que si les deux contrôles passent. Justifiez votre choix de structure de données pour la fenêtre glissante (journal exact vs approximation à deux seaux pondérés) et discutez des compromis mémoire/précision dans un court bloc de commentaire ou une note jointe. 3. **Concurrence** : Le limiteur sera sollicité par de nombreux threads/goroutines concurrentement pour le même `client_id` et pour des `client_id` différents. Évitez qu’un verrou global unique devienne un goulot d’étranglement (par ex. verrous par client ou lock striping). Documentez pourquoi votre approche est correcte sous des appels `allow` concurrents (pas de double-dépense de jetons, pas de mises à jour perdues). 4. **Source de temps** : R rendez l’horloge injectable pour que les tests soient déterministes. Utilisez par défaut une horloge monotone. 5. **Cas limites à traiter explicitement** : - `cost` plus grand que `burst` (doit être rejeté, ne jamais bloquer indéfiniment). - Horloge reculant ou pauses longues (par ex. VM suspendue) : plafonner plutôt que planter, et ne pas accorder de jetons illimités. - Première requête pour un client nouveau (initialisation paresseuse). - Nettoyage des clients obsolètes (la mémoire ne doit pas croître indéfiniment si des clients arrêtent d’appeler). - Jetons fractionnaires / timing sous-millisecondes. 6. **Tests** : Fournissez au moins 6 tests unitaires utilisant l’horloge injectable qui couvrent : autorisation/refus de base, vidage de rafale et recharge, plafond de la fenêtre glissante indépendant de la recharge du seau, `cost > burst`, contention concurrente sur un seul client (propriété déterministe : total permis en T secondes ≤ rate*T + burst), et éviction des clients obsolètes. 7. **Complexité** : Indiquez la complexité en temps amortie de `allow` et la complexité mémoire par client. Livrables : code exécutable complet (un seul fichier convient, mais vous pouvez scinder si vous les étiquetez clairement), les tests, et une brève note de conception (max ~250 mots) expliquant vos choix et la sémantique précise lorsque les deux algorithmes sont en désaccord.

190
12 May 2026 09:45

Affichage de 41 a 60 sur 537 resultats

Liens associes

X f L