Quando un ecosistema raggiunge un volume di traffico superiore al miliardo di token al minuto, la stabilità del servizio e l’efficienza dei costi dipendono interamente dalla capacità di gestire in modo intelligente la “prompt caching”. Questa tecnologia consente ai fornitori di modelli linguistici (LLM) di memorizzare i prefissi dei prompt già elaborati, riducendo drasticamente la latenza e i costi di inferenza. Tuttavia, il caching è estremamente sensibile: richiede che le richieste successive di uno stesso progetto siano indirizzate in modo coerente allo stesso provider, un requisito che entra in conflitto diretto con le strategie tradizionali di bilanciamento del carico e di failover.
Per risolvere questa dicotomia, Lovable ha sviluppato un sistema di routing interno basato sul concetto di “affinità a livello di progetto”. In un’architettura standard, se un provider come Anthropic restituisce un errore di limite di frequenza (rate limit), il sistema di routing globale reindirizzerebbe la richiesta successiva verso un fornitore alternativo, come Google Vertex o Amazon Bedrock. Sebbene questo garantisca la continuità del servizio, frammenta il contesto del prompt: il nuovo provider non possiede la cache del prefisso generata dal precedente, costringendo il sistema a rielaborare l’intero contesto da zero. Questo non solo aumenta i costi, ma può portare a un rapido esaurimento delle quote di calcolo (capacity) su tutti i fornitori disponibili, innescando un effetto domino di inefficienza.
La soluzione ingegneristica implementata si basa sulla generazione di catene di fallback multiple e differenziate. Invece di affidarsi a un’unica gerarchia globale di fornitori, il router di Lovable assegna a ogni progetto una specifica “catena di preferenza” calcolata dinamicamente. Questo meccanismo utilizza pesi variabili basati sulla disponibilità in tempo reale e sulle prestazioni storiche di ciascun endpoint. Quando un utente interagisce con un progetto, il sistema tenta sistematicamente di mantenere la connessione con il primo provider della catena assegnata. Solo in caso di guasti critici o saturazione persistente, il router scala verso il secondo anello della catena. Questo approccio preserva la “località” dei dati di caching, assicurando che la stragrande maggioranza delle operazioni di esplorazione del codice e di generazione mantenga uno stato “caldo” presso il fornitore primario.
Un aspetto tecnico cruciale riguarda il modo in cui i limiti di frequenza vengono calcolati dai provider moderni. Spesso, questi limiti sono definiti in base al numero di token non memorizzati (non-cached) inviati. Un sistema di routing che ignora il caching rischia di inviare costantemente prompt completi, consumando la quota disponibile molto più velocemente di un sistema che sfrutta la memoria dei prefissi. Attraverso l’ottimizzazione del routing, Lovable riesce a massimizzare la “cache hit rate”, riducendo la pressione computazionale sui server dei partner e garantendo agli utenti finali un’esperienza fluida anche durante i picchi di traffico globale. La gestione del traffico diventa quindi un esercizio di bilanciamento tra la ridondanza geografica e la persistenza dello stato logico del modello.
Infine, l’infrastruttura si avvale di un sistema di monitoraggio predittivo che riposiziona i carichi di lavoro prima che si verifichi un’interruzione totale. Analizzando i segnali di rallentamento o l’incremento degli errori parziali, il router può “raffreddare” un provider riducendo gradualmente il traffico di nuovi progetti verso di esso, mentre mantiene i progetti esistenti (e le loro relative cache) attivi fino al completamento della sessione. Questa gestione granulare trasforma il routing da una funzione di rete passiva a un componente attivo della logica applicativa, essenziale per sostenere lo sviluppo di applicazioni full-stack complesse generate interamente tramite linguaggio naturale.