La chiamata è arrivata alle 9:47 del Black Friday. Un negozio di moda belga aveva lanciato la promozione più importante dell'anno, preparata con settimane di campagne email, collaborazioni con influencer e pubblicità a pagamento. Il traffico è schizzato in alto esattamente come previsto, e il suo negozio PrestaShop è crollato del tutto entro la prima ora. I clienti che cliccavano su annunci preparati con cura trovavano pagine di errore, invece delle offerte a tempo limitato che gli erano state promesse. Il sito si rialzava per qualche minuto, mostrava poche pagine, poi crollava di nuovo, perché le richieste in coda saturavano la poca capacità che si liberava. Quando ci hanno contattato, avevano già perso oltre €40,000 di vendite previste e le ore più redditizie dell'anno stavano passando. Il provider di hosting ripeteva che i server erano a posto. Lo sviluppatore di prima non rispondeva al telefono. L'investimento in marketing stava svanendo in tempo reale.

→ Hai un'emergenza di prestazioni? Il nostro team risponde subito

I sintomi che hanno descritto indicavano un guasto a livello di database: quello schema preciso di ripresa parziale seguita da un nuovo crollo, che segnala l'esaurimento delle connessioni e non una semplice saturazione delle risorse. Con il traffico normale, la configurazione MySQL reggeva senza problemi la loro base di utenti contemporanei, piuttosto contenuta. Ma il traffico del Black Friday ha moltiplicato per cinquanta i visitatori simultanei, e ogni visitatore generava più query al database per i prodotti, il carrello e le sessioni. Il limite configurato di centocinquanta connessioni simultanee era sembrato generoso durante la pianificazione con lo sviluppatore precedente; sotto il carico reale delle festività si esauriva entro pochi minuti da ogni ripresa, e creava un ciclo in cui il database accettava le connessioni per un attimo, si saturava subito e rifiutava le nuove richieste finché le connessioni esistenti non andavano in timeout e si liberavano.

L'ambiente di hosting ha aggiunto altre complicazioni e ha allungato i tempi di risoluzione. Avevano scelto un provider di hosting gestito proprio per non doverci mettere le mani, ma quella semplicità significava niente accesso SSH, nessuna possibilità di modificare direttamente la configurazione MySQL e tempi di risposta del supporto misurati in ore, proprio mentre anche il provider era sommerso dalle richieste di assistenza del Black Friday. Le impostazioni delle prestazioni PrestaShop che potevamo regolare dalla configurazione di amministrazione, cioè cache, compilazione e modalità debug, erano già impostate correttamente. Il database stesso era ragionevolmente ottimizzato, e lo sviluppatore precedente aveva applicato le procedure di pulizia standard. Il problema stava al livello di infrastruttura, in configurazioni che l'ambiente di hosting impediva di proposito di modificare.

→ Non aspettare il Black Friday per scoprire i limiti dell'infrastruttura

Il nostro intervento di emergenza si è svolto su due binari paralleli. In primo luogo, abbiamo implementato una gestione immediata del traffico per ridurre il carico del database, preservando al contempo la massima capacità di vendita possibile. Versioni statiche di pagine prodotto critiche sono state distribuite su server edge CDN, consentendo ai clienti di consultare gli articoli promozionali chiave anche quando le operazioni dinamiche rimanevano inattive. Le funzionalità di carrello e checkout sono state prioritarie tramite un routing delle richieste che indirizzava connessioni limitate al database verso operazioni critiche per la conversione anziché verso la navigazione. Le operazioni amministrative sono state completamente bloccate per impedire al personale di consumare le connessioni necessarie per gli acquisti dei clienti. Queste misure hanno permesso al negozio di funzionare a capacità ridotta, ben lungi dall'essere ideale, ma generando vendite anziché solo errori.

Il secondo approccio ha affrontato le cause profonde attraverso l'escalation dell'infrastruttura. Collaborando con il team di escalation di emergenza del provider di hosting, abbiamo negoziato modifiche temporanee alla configurazione che hanno aumentato il numero massimo di connessioni al database e i processi di lavoro PHP oltre i limiti standard gestiti. L'allocazione di memoria per i processi PHP è stata ampliata per prevenire l'esaurimento di memoria che aveva contribuito a guasti a cascata. Nel primo pomeriggio, circa quattro ore dopo il crash iniziale, lo store si era stabilizzato a piena capacità, con l'infrastruttura temporaneamente riconfigurata per gestire il traffico generato dalla promozione. Le vendite sono riprese a volumi che, pur ridotti rispetto a quelli che avrebbero raggiunto con un'attività giornaliera completa, hanno consentito di recuperare entrate significative da quella che sembrava una perdita totale.

L'analisi successiva ha mostrato un'infrastruttura mai dimensionata davvero per il traffico che il team di marketing era in grado di generare. Il loro hosting PrestaShop bastava per il lavoro di tutti i giorni e per picchi promozionali modesti, ma le campagne importanti si basavano su ipotesi di capacità che nessuno aveva verificato con test di carico. Il limite di centocinquanta connessioni al database reggeva circa cento visitatori contemporanei, in base a come il sito interrogava il database: molto al di sotto delle migliaia che una campagna Black Friday riuscita avrebbe attirato. La memoria prevista dal loro piano di hosting non poteva sostenere il numero di worker PHP necessario per reggere molti accessi contemporanei. Questi limiti restavano invisibili nel funzionamento normale e saltavano fuori in modo catastrofico solo quando il marketing riusciva esattamente alla scala a cui puntavano.

La soluzione che abbiamo messo in atto per le stagioni successive ha chiuso queste vulnerabilità con un'architettura pensata per il picco, non per il traffico di tutti i giorni. L'infrastruttura del database è stata migrata su un hosting MySQL dedicato, con limiti di connessione allineati al traffico che volevano reggere. I server web sono stati configurati dietro un bilanciamento del carico in grado di crescere in orizzontale, aggiungendo server nei periodi promozionali. Abbiamo introdotto la cache Redis per ridurre dell'ottanta per cento il volume di query al database, e la capacità effettiva è aumentata in modo netto. I test di carico hanno confermato che la nuova architettura reggeva diecimila utenti contemporanei senza perdita di prestazioni: una capacità in grado di assorbire anche promozioni di successo oltre le previsioni, senza che l'infrastruttura diventasse il limite.

Il tuo negozio è pronto per la prossima grande opportunità?

I €40,000 di vendite perse nel Black Friday di questo commerciante sono solo il danno che si misura subito: il fatturato dei visitatori che hanno provato a comprare nelle ore in cui il sito era giù. I costi che non si vedono nei numeri includono relazioni con i clienti rovinate dalle pagine di errore, la reputazione del marchio colpita dalle lamentele sui social e l'investimento pubblicitario sprecato su visite che hanno trovato errori invece di un negozio. Ogni negozio PrestaShop che pianifica una promozione importante corre lo stesso rischio, se l'infrastruttura non è stata messa alla prova sul traffico di picco atteso. La domanda non è se riuscirai a portare traffico: il tuo team di marketing sta lavorando proprio per quel risultato. La domanda è se la tua infrastruttura trasformerà quel traffico in vendite o in un caso studio su cosa succede quando la preparazione non sta al passo con l'ambizione.

→ Verifica la tua infrastruttura prima della prossima campagna