TL;DR: aggiungere RAM risolve in fretta un limite di capacità, ma non corregge i byte sprecati a ogni record. Cloudflare ha recuperato circa 100 TB riprogettando la propria cache DNS: meno memoria per entry e, nello stesso test, più velocità. Per PMI e team web la regola è semplice: scalare l’hardware durante un’emergenza o quando il carico cambia ancora; ottimizzare dati e cache quando il workload è stabile, misurabile e abbastanza ripetitivo da ripagare il lavoro tecnico.
Il 27 agosto 2026 Cloudflare ha spiegato come ha ridotto la memoria usata da Big Pineapple, la piattaforma dietro 1.1.1.1 e altri servizi DNS. Il sistema conserva oltre 250 miliardi di entry: a quella scala, un solo byte inutile per entry pesa più di 250 GB sull’intera flotta.
La risposta più immediata sarebbe stata aumentare la RAM. Cloudflare ha scelto l’altra strada: cambiare la rappresentazione dei dati. Cinque interventi hanno portato il footprint misurato per entry da 953 a 420 byte, una riduzione del 56%. L’azienda stima circa 100 TB di memoria liberata. Nei benchmark dichiarati, il throughput di inserimento è salito del 43% e la latenza di lookup è scesa del 19%.
Il caso è estremo, ma la decisione riguarda anche un e-commerce WordPress, un CRM o un’automazione AI. Quando la memoria si riempie, conviene comprare capacità oppure rimuovere l’overhead?
Il criterio: costo per lavoro utile
Confronto i due approcci su quattro variabili: tempo per intervenire, costo ricorrente, rischio tecnico e prestazioni per unità di memoria. Non basta guardare quanti gigabyte restano liberi. Una soluzione è migliore se aumenta il lavoro utile senza rendere il sistema fragile o difficile da mantenere.
“Lavoro utile” cambia con il contesto. In un DNS è una risposta servita. In WordPress può essere una pagina consegnata senza interrogare di nuovo database e API. In un workflow AI è un documento elaborato e approvato, non il numero di token mossi.
Approccio A: aggiungere RAM e scalare l’infrastruttura
Lo scale-up ha un vantaggio difficile da battere: è rapido. Se un processo va in out-of-memory durante una campagna o un’importazione, aumentare il limite del container o passare a un’istanza più grande riduce il rischio operativo. Non serve cambiare il modello dati mentre il servizio è sotto pressione.
È anche la scelta più prudente quando il prodotto cambia spesso. Ottimizzare oggi una struttura che verrà sostituita tra un mese significa pagare due volte: prima l’analisi, poi la migrazione. La capacità aggiuntiva compra tempo e mantiene aperte più opzioni.
Il contro è economico e architetturale. La spesa si ripete ogni mese, cresce con repliche e ambienti e può nascondere un difetto che continua a moltiplicarsi. Se ogni oggetto porta metadati inutili, raddoppiare la RAM rinvia il problema; non lo elimina. Inoltre, più memoria non garantisce automaticamente meno latenza: allocazioni, serializzazione e accessi sparsi restano.
Approccio B: rendere i dati più compatti
Cloudflare ha lavorato sul costo di ogni entry. Ha sostituito contenitori espandibili con strutture a dimensione fissa dove i dati non cambiano dopo l’inserimento, unificato più liste in un buffer contiguo, eliminato nomi duplicati ricostruibili in lettura e conservato parte dei record nel formato binario DNS. Meno allocazioni e una migliore località in memoria hanno ridotto sia spazio sia tempo di accesso.
Questo approccio vince quando l’overhead è piccolo ma ripetuto moltissime volte. La documentazione Redis mostra lo stesso principio: la scelta tra stringhe, hash, JSON e strutture specializzate cambia memoria, funzionalità e costo di elaborazione. Il modello logico non è neutrale rispetto alla RAM.
Il rischio è spostare complessità nel codice. Dati più compatti possono richiedere conversioni, migrazioni, compatibilità tra versioni e benchmark dedicati. Il guadagno va misurato su traffico reale: Cloudflare stessa distingue i test per entry dalla memoria residente del processo, che include anche tutto il resto.
Il confronto, senza scorciatoie
| Criterio | Più RAM | Dati più compatti |
|---|---|---|
| Tempo di intervento | Ore o pochi giorni | Analisi, sviluppo e rollout |
| Costo | Ricorrente | Ingegneria iniziale e manutenzione |
| Rischio | Basso nel breve periodo | Più alto durante migrazione e compatibilità |
| Efficienza | Non cambia il costo per record | Può ridurre memoria, allocazioni e latenza |
| Quando conviene | Picchi, incidenti, prodotto instabile | Carichi stabili, grandi e ripetitivi |
Cosa cambia per WordPress e il web
WordPress usa l’Object Cache per evitare lavoro costoso, come ripetere query al database. Per impostazione predefinita quella cache dura una sola richiesta; per mantenerla tra richieste serve un backend persistente, per esempio Redis o Memcached. Questo non significa che ogni sito debba installare Redis. Una pagina cache servita prima di avviare PHP può togliere molto più carico con meno complessità.
L’ordine corretto è misurare, poi scegliere il livello. Controllerei hit rate, eviction, memoria per chiave, query lente, dimensione dei transient e chiamate esterne duplicate. Se il collo di bottiglia è il database, un object cache persistente può aiutare. Se la cache cresce per chiavi troppo lunghe, valori JSON gonfi o TTL sbagliati, aggiungere RAM finanzia lo spreco.
La stessa logica vale per l’infrastruttura AI, dove RAM ed energia sono vincoli reali. Prima di comprare capacità, bisogna capire se il workload usa quella capacità per dati utili o per copie, padding e formati comodi ma costosi.
Automazioni e AI: ottimizzare ciò che si ripete
In n8n, Make o in uno script custom vedo spesso payload completi copiati tra nodi, log senza scadenza e risultati AI salvati più volte. Qui l’ottimizzazione non richiede trucchi da data center: basta separare il dato canonico dai riferimenti, imporre retention e non conservare il contesto intero quando serve solo un ID o un esito.
Per l’AI locale il rischio di sovradimensionare è ancora più evidente. Nel confronto tra AI locale e API cloud per le PMI, la convenienza dipendeva dal volume e dal controllo richiesto. Anche qui una macchina più grande ha senso solo dopo aver misurato picco, coda, latenza e costo per output approvato.
La mia take: scala per respirare, ottimizza per restare
Se il servizio è in crisi, sceglierei A: più RAM, margine operativo e tempo per raccogliere dati. Non si ridisegna una cache durante un incidente. Ma quella deve essere una misura temporanea con una data di revisione.
Per un carico stabile sceglierei B. Profilerei allocazioni e hit rate, cambierei una rappresentazione alla volta e confronterei memoria e latenza prima e dopo. Cloudflare non ha dimostrato che l’hardware sia inutile. Ha dimostrato che, quando ogni byte viene moltiplicato abbastanza volte, l’efficienza software diventa capacità infrastrutturale.