Skip to main content

Corriger la latence du checkout avec trois stratégies concurrentes

Lancez 3 sessions Devin en parallèle face à une API de checkout lente — chacune essaie une optimisation différente, puis la meilleure approche est déployée.
AuthorCognition
CategoryOptimisation Devin
FeaturesAvancé
1

Définir le problème et les critères de succès

Votre API de checkout (POST /api/checkout) a une latence p99 de 1,8 seconde : les utilisateurs abandonnent leur panier et votre objectif de SLA est de 400 ms. Il existe plusieurs approches possibles pour y remédier : mise en cache, optimisation des requêtes, traitement asynchrone, pool de connexions. Vous ne savez pas laquelle fonctionnera le mieux avant de les avoir essayées, et les tester séquentiellement signifie attendre plusieurs jours.Au lieu de cela, utilisez Advanced Devin pour lancer 3 sessions en parallèle, chacune explorant une stratégie différente. Une fois les 3 terminées, Advanced Devin compare les résultats et déploie la solution gagnante — ou combine les meilleurs éléments de chacune en un seul PR.Pour commencer, sélectionnez Advanced dans le sélecteur d’agents sur la page d’accueil de Devin, puis cliquez sur l’onglet Start Batch Sessions.
2

Rédigez un prompt qui guide chaque session vers une correction différente

La valeur du lancement de 3 sessions dépend du fait que chacune explore une approche réellement différente. Rédigez votre prompt pour encourager la divergence — suggérez des stratégies spécifiques et définissez ce que signifie “best” afin que les résultats soient directement comparables.Conseils pour un bon prompt multi-stratégie :
  • Définissez “best” avec des critères hiérarchisés. Énumérer les dimensions de comparaison — latence, taux d’erreur, complexité, cohérence — empêche Devin de se limiter à la vitesse brute.
  • Suggérez des stratégies spécifiques. Des options comme “caching, query rewriting, async processing” orientent chaque session vers une voie différente.
  • Incluez une commande de benchmark. Chaque session a besoin d’un moyen reproductible de mesurer son propre résultat — npm run bench, k6 run load-test.js ou une simple boucle curl.
  • Pointez vers le code. Un chemin de fichier comme src/routes/checkout.ts garantit que les 3 sessions partent toutes du même point.
3

Comparez les résultats et choisissez le meilleur

Une fois les 3 sessions terminées, Advanced Devin passe en revue leur travail côte à côte selon vos critères — stratégies utilisées, chiffres de référence, arbitrages — et sélectionne soit la meilleure option, soit synthétise une solution combinée sous la forme d’une pull request (PR) finale.Voici à quoi ressemble cette comparaison pour le problème de latence du checkout :
Session 1 — Redis response caching
  Strategy:   Cache serialized cart + inventory lookups in Redis with
              30s TTL, bypass DB for repeat requests
  p99:        1.8s -> 320ms  (PASS — 82% reduction)
  Errors:     No change
  Complexity: +1 dependency (ioredis), 2 new files
  Tradeoff:   Stale inventory data for up to 30s; 40MB Redis memory

Session 2 — Query optimization + connection pooling
  Strategy:   Replaced N+1 queries with a single JOIN, added PgBouncer
              connection pool (25 connections)
  p99:        1.8s -> 580ms  (FAIL — still above 400ms)
  Errors:     No change
  Complexity: 0 new dependencies, cleaner queries
  Tradeoff:   None significant — lower DB load overall

Session 3 — Async order processing
  Strategy:   Moved payment processing and email to a background queue
              (BullMQ), return 202 immediately after inventory check
  p99:        1.8s -> 190ms  (PASS — 89% reduction)
  Errors:     No change
  Complexity: +1 dependency (bullmq), 3 new files, webhook handler
  Tradeoff:   Checkout becomes eventually consistent; needs webhook
              for payment confirmation

Verdict: Sessions 1 and 3 both pass the 400ms target. Session 2's
query fixes are valuable but insufficient alone.

Final PR: Combined Session 2's query optimization (no cost, strictly
better) with Session 3's async processing. Payment + email moved to
queue, N+1 queries fixed. Final p99: 150ms. PR #412 opened.
Vous pouvez revoir les PR de chaque session avant qu’Advanced Devin ne crée la PR combinée. Si vous préférez une approche en particulier, dites simplement à Devin : “adopte l’approche de la session 3 et ignore la combinaison.”
4

Quand lancer 3 stratégies en parallèle sur un même problème

Bon cas d’utilisation — plusieurs approches valides existent :
  • Goulots d’étranglement de performances où la mise en cache, l’optimisation des requêtes et des changements d’architecture pourraient tous fonctionner
  • Décisions d’architecture avec de vrais compromis (extraction d’un monolithe, refonte de la gestion d’état)
  • Choix d’algorithme pour un problème très volumineux en données (différents index, méthodes de classement ou approches de ML)
Mauvais cas d’utilisation — la solution est évidente :
  • Corrections de bugs avec une cause fondamentale claire
  • Ajout d’un endpoint CRUD standard
  • Mise à jour de dépendances ou de fichiers de configuration
Ce mode utilise 3× plus d’ACU qu’une seule session. Réservez-le aux problèmes pour lesquels vous passeriez autrement des jours à essayer des approches de manière séquentielle. Pour les tâches simples, une seule session Devin est plus rapide et moins coûteuse.Vous pouvez aussi déclencher des sessions par lots via l’API en définissant advanced_mode sur batch — utile pour l’intégration dans des pipelines CI qui mettent automatiquement en concurrence plusieurs correctifs face à une régression de performances. Si vous voulez que Devin fonctionne de manière entièrement autonome sans attendre votre approbation sur les propositions, activez le paramètre bypass permissions pour que les sessions soient automatiquement approuvées et puissent se poursuivre.