La mattina di una campagna promozionale, sul vostro schermo accadono tre cose contemporaneamente: le vendite, il numero di visitatori e — se la vostra infrastruttura non è pronta — le pagine di errore. Restare online sotto un traffico elevato non è questione di fortuna, ma dipende da un'architettura progettata in anticipo. In questo articolo vediamo come CDN, caching e scalabilità orizzontale mantengono il vostro sito operativo senza interruzioni nei giorni di campagna, con passaggi pratici.
Perché i siti vanno in crash il giorno della campagna?
Il crash di un sito e-commerce sotto traffico raramente ha una causa unica; di solito si tratta di tre problemi che si sommano: un numero di richieste simultanee che un singolo server non riesce a gestire, query al database pesanti eseguite ripetutamente a ogni richiesta e file statici (immagini, script, fogli di stile) rigenerati dal server ogni volta. Nei giorni normali questi problemi passano inosservati, perché il server si appoggia sulla capacità inutilizzata. Quando il traffico del giorno di campagna aumenta di 10-20 volte, la stessa capacità non basta più e il sistema si blocca sotto una coda di richieste.
La soluzione non è acquistare "un server grande." La vera soluzione è distribuire il carico sui livelli giusti e far sì che ciascun livello svolga il proprio compito nel modo più efficiente possibile. I quattro livelli seguenti costituiscono l'ossatura di questa distribuzione.
CDN: spostare il traffico al margine, non all'origine
Una rete di distribuzione dei contenuti (CDN) serve le risorse statiche — immagini, script e fogli di stile — dal server geograficamente più vicino all'utente. In questo modo il vostro server di origine non deve inviare lo stesso file più e più volte a ogni richiesta; si occupa solo dei contenuti effettivamente dinamici e in continuo cambiamento.
- La maggior parte delle risorse statiche (immagini, CSS, JS) dovrebbe essere servita tramite CDN, dal punto più vicino all'utente,
- Le immagini prodotto dovrebbero essere ottimizzate e generate in anticipo per diverse dimensioni di schermo,
- I tempi di cache della CDN vanno calibrati sulla frequenza di modifica dei contenuti: lunghi per i file che cambiano raramente, brevi per quelli che cambiano spesso.
Il vantaggio della CDN non è solo la velocità; riducendo in modo significativo il carico sul vostro server di origine, libera quella capacità per ciò che conta davvero — creare ordini, verificare le scorte, elaborare i pagamenti. Il giorno della campagna, questa separazione è uno dei fattori più determinanti nel decidere se il sito reggerà o meno. Abbiamo approfondito l'impatto della CDN sulla velocità nel contesto dei Core Web Vitals in un altro articolo.
Livelli di caching: pagina, query e oggetto
La CDN gestisce i file statici, ma le pagine dinamiche (elenco prodotti, pagine categoria, risultati di ricerca) non devono interrogare il database a ogni singola visita. Il caching significa calcolare un risultato una volta e riutilizzarlo per un certo periodo; il giorno della campagna, quando migliaia di persone visualizzano la stessa scheda prodotto, condividere un unico risultato calcolato invece di interrogare il database migliaia di volte è ciò che salva il vostro server.
- Cache di pagina: le pagine che cambiano raramente (categoria, campagna, contenuti statici) possono essere memorizzate come pagina intera per qualche minuto,
- Cache di query: i dati letti spesso ma scritti raramente, come scorte e prezzi, vengono mantenuti in un livello di cache in memoria (ad esempio Redis),
- Cache di oggetto: le strutture costose da calcolare ma che cambiano raramente, come menu o alberi di categorie, vengono messe in cache e svuotate quando avviene un vero cambiamento.
La parte più difficile del caching è decidere quando aggiornarlo. Per i dati che richiedono accuratezza in tempo reale, come i livelli di scorta, la durata della cache va tenuta molto breve, oppure la cache va invalidata istantaneamente quando le scorte cambiano; altrimenti un prodotto esaurito può continuare a risultare "disponibile" nella cache.
Scalabilità orizzontale: aumentare il numero di server in base alla domanda
La scalabilità verticale consiste nel potenziare un singolo server con hardware più performante; oltre un certo punto diventa insostenibile, sia per i costi che per i limiti fisici. La scalabilità orizzontale consiste invece nell'attivare più server che svolgono lo stesso lavoro e nel distribuire il traffico in arrivo tra questi tramite un load balancer.
La forza di questo modello sta nella sua flessibilità: due o tre server possono bastare in un giorno normale, ma quel numero può essere portato a dieci, automaticamente o manualmente, prima di una campagna, e poi ridotto di nuovo una volta terminata. Perché la scalabilità orizzontale funzioni, l'applicazione deve essere progettata come "stateless" — cioè i dati di sessione utente o del carrello non devono risiedere nella memoria di un singolo server, ma in un livello condiviso (un database o Redis) accessibile a tutti i server. Altrimenti, quando le richieste di un utente finiscono su server diversi, il suo carrello può sembrare "sparito."
Per chiarire quando scegliere l'uno o l'altro approccio, è utile mettere a confronto le differenze principali:
| Dimensione | Scalabilità Verticale | Scalabilità Orizzontale |
|---|---|---|
| Metodo | Potenziare un singolo server con hardware più performante | Aumentare il numero di server che svolgono lo stesso lavoro |
| Curva dei costi | Cresce in modo sproporzionato oltre un certo punto | Lineare, flessibile in base alla domanda |
| Rischio di interruzione | Punto singolo di fallimento; se il server si guasta, il sito si ferma | Se un server si guasta, gli altri continuano a lavorare |
| Limite di scala | Termina con i limiti fisici dell'hardware | In pratica non esiste un limite superiore netto |
| Prerequisito | Nessun requisito aggiuntivo | L'applicazione deve essere progettata come stateless |
"Il giorno della campagna non è il giorno in cui testate la vostra infrastruttura, è il giorno in cui la vostra infrastruttura testa voi. La preparazione inizia settimane prima che arrivi quel giorno."
Il collo di bottiglia del database: il punto più spesso trascurato
Aggiungere altri server è facile; il vero collo di bottiglia si concentra di solito in un unico database. Poiché tutti i server leggono e scrivono sullo stesso database, il carico su di esso cresce con il numero dei server e, a un certo punto, il database diventa l'anello più debole dell'intera architettura.
Qui aiutano tre misure: leggere dalla cache, anziché dal database, i dati letti spesso ma modificati raramente; servire le query ad alta intensità di lettura tramite una "replica di lettura" separata dal database primario; e mettere in coda le operazioni critiche e sensibili alla concorrenza, come lo scarico delle scorte, per evitare che il database riceva migliaia di richieste di scrittura simultanee. Il queuing è uno dei metodi più efficaci per attutire i picchi di carico improvvisi, in particolare nei momenti di "aggiungi al carrello" e "crea ordine."
Test di carico prima della campagna
Per quanto ben progettata sia l'architettura, affrontare il giorno della campagna senza averla testata con traffico reale è rischioso. Il test di carico permette di individuare in anticipo il punto di rottura del sito, usando strumenti che simulano diverse volte il numero di visitatori previsto.
- Costruite uno scenario che punti a 2-3 volte il picco di traffico previsto, basandovi sui dati delle campagne precedenti,
- Non limitatevi a testare la homepage — includete anche la scheda prodotto, il carrello e il flusso di checkout, poiché il vero collo di bottiglia si presenta di solito proprio al pagamento,
- Eseguite il test almeno una settimana prima della campagna, in modo da avere il tempo di correggere i problemi riscontrati e ritestare.
Stimare il traffico atteso richiede la stessa disciplina di pianificazione anche sul fronte delle scorte; abbiamo approfondito la previsione della domanda pre-stagionale nella nostra guida sulla previsione della domanda.
Monitoraggio in tempo reale e allarmi automatici
Lo scenario più pericoloso il giorno della campagna è un problema che cresce senza essere notato. Configurate una dashboard che monitori in tempo reale indicatori come il tempo di risposta del server, il tasso di errore e la lunghezza delle code, in modo che il team riceva una notifica automatica quando vengono superate soglie predefinite. Definire una regola che attivi automaticamente la scalabilità orizzontale in base al traffico aumenta la capacità senza attendere l'intervento manuale del team.
Un altro vantaggio del monitoraggio è la valutazione post-campagna: sapere a che ora si è verificato il picco, quale pagina ha generato più carico e quanta della capacità disponibile è stata utilizzata rende la pianificazione della campagna successiva molto più precisa.
Conclusione
Restare online sotto un traffico elevato non significa acquistare un server potente, ma disporre di un'architettura che distribuisce il carico sui livelli giusti (CDN, cache, server applicativi, database) e che può crescere e ridursi in base alla domanda. Testare questa architettura prima del giorno della campagna vi permette di risolvere i problemi prima che i clienti se ne accorgano. Per pianificare insieme il vostro calendario di campagne e questa preparazione infrastrutturale, potete consultare la nostra guida alla preparazione per il Black Friday.
Checklist rapida
- Le vostre risorse statiche vengono servite tramite CDN?
- Avete un livello di cache per i dati letti di frequente?
- Riuscite ad aumentare il numero di server in base alla domanda?
- I dati di sessione/carrello sono accessibili su tutti i server?
- Le operazioni di scrittura critiche vengono gestite tramite una coda?
- Avete eseguito un test di carico prima dell'ultima campagna?
- Disponete di monitoraggio in tempo reale e allarmi automatici?
Costruire questa infrastruttura da zero è un lavoro di ingegneria che richiede il team giusto e il tempo necessario. La piattaforma e-commerce di Şimşek Software integra di serie l'integrazione CDN, il caching multilivello e un'architettura server che scala in base alla domanda: potrete così concentrarvi sulle vendite senza preoccuparvi dell'infrastruttura il giorno della campagna.