Ci sono notti di dicembre in cui non guardo il fatturato: guardo i grafici. La response time media del checkout, gli hit ratio della cache, la CPU dei nodi applicativi. Negli anni ho imparato che il picco di fine anno non si vince con l’eroismo dell’ultimo minuto, ma con le decisioni prese settimane prima. Progettando e gestendo piattaforme Adobe Commerce per merchant che a novembre e dicembre fanno una fetta enorme del loro anno, mi sono fatto un’idea precisa su cosa regge davvero sotto pressione e cosa, invece, va lasciato andare.
Questo pezzo è il dietro le quinte di come tengo in piedi un Adobe Commerce quando il traffico si moltiplica: Full Page Cache, Varnish, Redis, indexer, database, hosting, monitoring e il runbook che tiro fuori quando qualcosa va storto. E, soprattutto, di cosa proteggo e cosa sacrifico quando la pressione sale.
Cosa succede davvero quando arriva il picco
Un Adobe Commerce a riposo e lo stesso store durante una promo sono due animali diversi. A riposo la maggior parte delle richieste tocca pagine cacheabili: home, categorie, schede prodotto. Sotto picco cambia il mix. Cresce la quota di traffico non cacheabile — carrello, checkout, login, ricerche interne — cioè esattamente le pagine che colpiscono PHP, MySQL e Redis senza schermo davanti. Il collo di bottiglia, sotto picco, non è servire una pagina in più: è servire quella specifica pagina che nessuna cache può proteggere.
La mia regola è banale ma la ripeto a ogni progetto: più il traffico sale, più conta cosa non passa dalla cache. Ottimizzare la home mentre il checkout affonda è tempo buttato.
Full Page Cache e Varnish: la prima linea
Su Adobe Commerce non uso mai il Full Page Cache interno (quello su Redis o filesystem) come difesa principale in produzione. Metto Varnish davanti, sempre. È l’unico modo serio per assorbire migliaia di richieste anonime senza nemmeno svegliare PHP. Un merchant fashion che seguivo — ordine di grandezza mid-market europeo — passava da qualche centinaio a diverse migliaia di utenti simultanei nelle sere di lancio: con un hit ratio Varnish sopra il 90% sulle pagine anonime, il cluster applicativo restava quasi annoiato.
Le tre cose che controllo prima del picco, in ordine:
- Cache warming delle pagine chiave (categorie in campagna, landing, best seller) fatto prima dell’ondata, non durante.
- TTL onesti: alzo la durata della cache sulle pagine che cambiano poco e accetto che un prezzo si aggiorni con qualche minuto di ritardo. Sotto picco, la freschezza al secondo è un lusso che non serve.
- Nessun blocco dinamico di troppo nelle pagine cacheabili. Ogni sezione marcata come non cacheabile via ESI o hole punching è un buco nella diga. A dicembre quei buchi li chiudo.
Redis: sessioni e cache, ma separate
Qui vedo l’errore più comune. Redis su Adobe Commerce fa due lavori distinti — session storage e backend cache — e vanno tenuti su istanze separate. Se li mescoli, un flush della cache durante una promo ti porta via anche le sessioni, e ti ritrovi carrelli svuotati proprio mentre la gente sta pagando. L’ho visto succedere, non lo voglio rivedere.
La mia opinione, netta: durante il picco non si tocca la cache in produzione se non si è costretti. Niente deploy di configurazione, niente flush “per sicurezza”. Ogni flush a traffico alto è una piccola valanga di richieste che ripartono a freddo tutte insieme, e il database se ne accorge subito.
Indexer e database: dove si nasconde il vero collo di bottiglia
Gli indexer sono la mia ossessione stagionale. Li tengo tutti in modalità update on schedule, mai on save: non voglio che un aggiornamento di stock o prezzo faccia partire una reindicizzazione pesante mentre migliaia di persone navigano. La reindicizzazione la programmo nelle ore morte e, nei giorni caldi, riduco al minimo le modifiche massive al catalogo. Se un merchant vuole caricare tremila prodotti il pomeriggio del lancio, la risposta è no — e spiego perché.
Il database è l’ultima linea e la più fragile. Sotto picco i punti che sorveglio sono sempre gli stessi: le query lente sul carrello e sul checkout, la tabella delle quote che cresce, i lock in scrittura sugli ordini. Un read replica per alleggerire le letture aiuta, ma non fa miracoli: gli ordini si scrivono sul primary, e lì il numero di connessioni e la latenza sono i due indicatori che tengo sotto gli occhi tutta la sera.
Hosting e autoscaling: utile, ma non è una bacchetta magica
L’autoscaling sui nodi applicativi funziona bene per il traffico PHP, ed è giusto averlo. Ma diffido di chi lo vende come soluzione a tutto. Puoi scalare orizzontalmente lo strato applicativo in pochi minuti; non scali il database primary con la stessa disinvoltura. Per questo dimensiono l’infrastruttura in anticipo sui numeri attesi, con un margine, invece di affidarmi a uno scaling reattivo che entra in gioco quando la coda è già partita. Lo scaling automatico è una rete di sicurezza, non il piano.
Monitoring: guardare le cose giuste
Nei giorni di picco non guardo decine di dashboard. Ne guardo poche, ma quelle giuste. I miei indicatori di salute reale sono quattro: tempo di risposta del checkout, hit ratio di Varnish, saturazione CPU dei nodi applicativi e connessioni attive sul database. Se questi quattro stanno bene, lo store è in salute anche se qualche pagina secondaria è lenta. Metto alert su soglie che scattano prima del problema, non quando il sito è già giù: un p95 del checkout che sale è un avviso, non un incidente — se lo prendi in tempo.
Il runbook: decidere prima, non nel panico
Nessuno ragiona bene alle due di notte con il sito lento e il telefono che squilla. Per questo il runbook lo scrivo a mente fredda, settimane prima, e contiene azioni concrete: come e in che ordine degradare le funzioni non essenziali, chi ha l’autorità di premere quali bottoni, come si isola un servizio che sta trascinando giù il resto. Non è burocrazia. È il modo per trasformare un incidente in una procedura invece che in una crisi.
Cosa proteggo e cosa sacrifico
Ecco il cuore della faccenda, la parte che chi non ha gestito un picco spesso salta. Quando la pressione sale, non tutto può vivere. Le priorità le decido prima, e sono queste.
Proteggo, a ogni costo: l’add to cart, il checkout, il pagamento. Se un cliente riesce ad aggiungere al carrello e pagare, la serata è salva. Tutto il resto è negoziabile.
Sacrifico, senza sensi di colpa: ricerca interna con filtri pesanti (posso servire risultati semplificati), sezioni “prodotti correlati” e raccomandazioni dinamiche, feature social e recensioni caricate a runtime, aggiornamenti di stock al secondo. Preferisco mostrare uno stock leggermente in ritardo che far cadere il checkout. La graceful degradation non è una sconfitta: è la scelta consapevole di rinunciare al superfluo per proteggere l’essenziale.
La verità che ho imparato sul campo è che reggere il picco è più una questione di disciplina che di potenza. La potenza si compra; la disciplina di decidere in anticipo cosa conta, no. I nervi saldi, a dicembre, vengono da lì: dal sapere già cosa farai quando qualcosa andrà storto — perché qualcosa, prima o poi, va sempre storto.
In sintesi
- Sotto picco, il collo di bottiglia non sono le pagine cacheabili ma checkout, carrello e login, che nessuna cache protegge.
- Varnish davanti ad Adobe Commerce, con hit ratio sopra il 90% sulle pagine anonime, è la prima e più efficace linea di difesa.
- Redis va separato tra session storage e backend cache, per evitare che un flush della cache svuoti i carrelli.
- Gli indexer vanno tenuti in modalità update on schedule, mai on save, durante i periodi di traffico alto.
- L’autoscaling scala lo strato applicativo in minuti, ma non il database primary: l’infrastruttura va dimensionata in anticipo.
- Quando la pressione sale si proteggono add to cart, checkout e pagamento, e si sacrificano ricerca pesante, raccomandazioni e freschezza dello stock.
Domande frequenti
Meglio il Full Page Cache interno di Adobe Commerce o Varnish?
In produzione, sotto picco, uso Varnish come cache primaria. Assorbe le richieste anonime senza svegliare PHP e regge volumi che il Full Page Cache interno non gestisce con la stessa efficienza.
Perché non affidarsi solo all’autoscaling per i picchi di dicembre?
Perché l’autoscaling scala bene i nodi applicativi PHP, ma non il database primary, dove si scrivono gli ordini. Dimensiono l’infrastruttura in anticipo sui numeri attesi e uso lo scaling come rete di sicurezza, non come piano principale.
Cosa conviene sacrificare quando lo store è sotto stress?
Ricerca interna con filtri pesanti, raccomandazioni e prodotti correlati dinamici, feature social a runtime e freschezza dello stock al secondo. Si protegge invece tutto il percorso di acquisto: add to cart, checkout e pagamento.
Come evito che un flush della cache mandi in crisi il sito durante una promo?
Tengo separate le istanze Redis di sessione e cache, evito flush non necessari a traffico alto e faccio cache warming delle pagine chiave prima dell’ondata, non durante.
Sono Fabio Canovi, mi occupo di e-commerce enterprise su Magento e Adobe Commerce da quando lavoro su questa piattaforma, e sono tra i primi in Italia ad aver conseguito la certificazione Adobe Commerce. Su questo blog racconto, dal di dentro, come funzionano davvero le cose che vendono online.