Skip to main content

Riduci la latenza del checkout con tre strategie concorrenti

Metti in competizione 3 sessioni Devin in parallelo contro un'API di checkout lenta — ognuna prova un'ottimizzazione diversa, quindi porta in produzione l'approccio migliore.
AuthorCognition
CategoryOttimizzazione con Devin
FeaturesAvanzato
1

Definire il problema e i criteri di successo

La tua API di checkout (POST /api/checkout) ha una latenza p99 di 1,8 secondi — gli utenti abbandonano i carrelli e il tuo obiettivo di SLA è 400 ms. Esistono diversi modi validi per risolvere il problema: caching, ottimizzazione delle query, elaborazione asincrona, pooling delle connessioni. Non sai quale funzionerà meglio finché non li provi, e provarli in sequenza significa aspettare giorni.Invece, usa Advanced Devin per avviare 3 sessioni in parallelo, ognuna delle quali esplora una strategia diversa. Dopo che tutte e 3 hanno terminato, Advanced Devin confronta i risultati e applica la soluzione vincente — oppure combina le parti migliori di ognuna in una singola PR.Per iniziare, seleziona Advanced dal selettore dell’agente nella homepage di Devin, quindi fai clic sulla scheda Start Batch Sessions.
2

Scrivi un prompt che indirizzi ogni sessione verso una soluzione diversa

Il valore di eseguire 3 sessioni dipende dal fatto che ognuna esplori un approccio davvero diverso. Scrivi il tuo prompt in modo da incoraggiare la divergenza — suggerisci strategie specifiche e definisci cosa significa “migliore” così che i risultati siano direttamente confrontabili.Suggerimenti per un buon prompt multi-strategia:
  • Definisci “migliore” con criteri ordinati. Elencare le dimensioni di confronto — latenza, tasso di errore, complessità, consistenza — impedisce a Devin di privilegiare soltanto la velocità pura.
  • Suggerisci strategie specifiche. Opzioni come “caching, riscrittura delle query, elaborazione asincrona” spingono ciascuna sessione verso un percorso diverso.
  • Includi un comando di benchmark. Ogni sessione ha bisogno di un modo riproducibile per misurare il proprio risultato — npm run bench, k6 run load-test.js o un semplice loop curl.
  • Indica il codice. Un percorso di file come src/routes/checkout.ts assicura che tutte e 3 le sessioni partano dallo stesso punto.
3

Confronta i risultati e seleziona il vincitore

Una volta che tutte e tre le sessioni sono state completate, Advanced Devin esamina il lavoro prodotto confrontandolo con i tuoi criteri — strategie utilizzate, metriche di benchmark, compromessi — e poi sceglie la soluzione migliore oppure sintetizza una soluzione combinata in un’unica PR finale (pull request finale).Ecco come si presenta questo confronto per il problema della latenza nel checkout:
Sessione 1 — Caching delle risposte Redis
  Strategia:  Cache del carrello serializzato + lookup inventario in Redis con
              TTL di 30s, bypass del DB per richieste ripetute
  p99:        1.8s -> 320ms  (PASS — riduzione dell'82%)
  Errori:     Nessuna modifica
  Complessità: +1 dipendenza (ioredis), 2 nuovi file
  Compromesso: Dati inventario non aggiornati per un massimo di 30s; 40MB di memoria Redis

Sessione 2 — Ottimizzazione query + connection pooling
  Strategia:  Sostituzione delle query N+1 con un singolo JOIN, aggiunto PgBouncer
              connection pool (25 connessioni)
  p99:        1.8s -> 580ms  (FAIL — ancora sopra i 400ms)
  Errori:     Nessuna modifica
  Complessità: 0 nuove dipendenze, query più pulite
  Compromesso: Nessuno significativo — carico DB complessivamente inferiore

Sessione 3 — Elaborazione ordini asincrona
  Strategia:  Spostamento dell'elaborazione pagamenti e delle email in una coda in background
              (BullMQ), restituzione del 202 immediatamente dopo il controllo inventario
  p99:        1.8s -> 190ms  (PASS — riduzione dell'89%)
  Errori:     Nessuna modifica
  Complessità: +1 dipendenza (bullmq), 3 nuovi file, webhook handler
  Compromesso: Il checkout diventa eventually consistent; richiede webhook
              per la conferma del pagamento

Verdetto: Le sessioni 1 e 3 superano entrambe il target di 400ms. Le
correzioni alle query della sessione 2 sono utili ma insufficienti da sole.

PR finale: Combinata l'ottimizzazione delle query della sessione 2 (nessun costo aggiuntivo,
decisamente migliore) con l'elaborazione asincrona della sessione 3. Pagamenti + email spostati nella
coda, query N+1 corrette. p99 finale: 150ms. PR #412 aperta.
Puoi rivedere le singole PR di sessione prima che Advanced Devin crei quella combinata. Se preferisci chiaramente uno degli approcci, ti basta dirlo a Devin — “segui l’approccio della sessione 3, salta la combinazione.”
4

Quando far competere 3 strategie su un unico problema

Buon caso d’uso — esistono più approcci validi:
  • Collo di bottiglia delle prestazioni in cui caching, ottimizzazione delle query e modifiche all’architettura potrebbero funzionare tutte
  • Decisioni di architettura con tradeoff reali (estrazione da un monolite, riprogettazione della gestione dello stato)
  • Scelta dell’algoritmo per un problema fortemente basato sui dati (diverse strategie di indicizzazione, ranking o approcci di ML)
Cattivo caso d’uso — la soluzione è ovvia:
  • Correzioni di bug con causa principale chiara
  • Aggiunta di un endpoint CRUD standard
  • Aggiornamento di dipendenze o file di configurazione
Questo pattern utilizza 3 volte gli ACU di una singola sessione. Riservalo a problemi per cui altrimenti passeresti giorni a provare approcci in sequenza. Per attività semplici, una singola sessione di Devin è più veloce ed economica.Puoi anche attivare sessioni batch tramite l’API impostando advanced_mode su batch — utile per integrarle in pipeline CI che mettono automaticamente in competizione più correzioni per una regressione di prestazioni. Se vuoi che Devin venga eseguito in modo completamente autonomo senza attendere la tua approvazione sulle proposte, abilita il flag bypass permissions così le sessioni si approvano automaticamente e continuano ad avanzare.