Het telefoontje kwam om 9:47 uur 's ochtends op Black Friday. Een Belgische modewebwinkel had de grootste actie van het jaar gelanceerd, gedragen door weken aan e-mailcampagnes, samenwerkingen met influencers en betaalde advertenties. Het verkeer steeg precies zoals gepland—en hun PrestaShop-winkel crashte volledig binnen het eerste uur. Klanten die op zorgvuldig opgezette advertenties klikten, kregen foutpagina's in plaats van de tijdelijke aanbiedingen die hun beloofd waren. De site herstelde zich kort, toonde een handvol pagina's en stortte daarna opnieuw in, doordat wachtende verzoeken de capaciteit die even vrijkwam overspoelden. Tegen de tijd dat ze ons belden, hadden ze al meer dan €40,000 aan verwachte omzet verloren en tikten de drukste winkeluren van het jaar weg. Hun hostingprovider hield vol dat de servers in orde waren. Hun vorige ontwikkelaar nam de telefoon niet op. Hun marketinginvestering verdampte in realtime.

→ Heb je een prestatienood? Ons team reageert meteen

De symptomen die ze beschreven, wezen op een storing in de databaselaag—het specifieke patroon van gedeeltelijk herstel gevolgd door een nieuwe instorting, dat wijst op uitputting van verbindingen en niet op simpele verzadiging van de resources. Bij normaal verkeer droeg hun MySQL-configuratie hun bescheiden aantal gelijktijdige gebruikers zonder problemen. Maar Black Friday-verkeer vermenigvuldigde het aantal gelijktijdige bezoekers met een factor vijftig, en elke bezoeker genereerde meerdere databasequery's voor producten, winkelwagenacties en sessiebeheer. De ingestelde limiet van honderdvijftig gelijktijdige verbindingen leek ruim tijdens de planningsgesprekken met hun vorige ontwikkelaar. Onder de werkelijke piekbelasting van de feestdagen was die limiet binnen enkele minuten na elk herstel uitgeput. Zo ontstond een cyclus waarin de database kort verbindingen accepteerde, meteen verzadigde en nieuwe verzoeken weigerde tot bestaande verbindingen een time-out kregen en vrijkwamen.

De hostingomgeving zorgde voor extra complicaties die de oplostijd verlengden. Ze hadden een managed hostingprovider gekozen juist vanwege de zorgeloze eenvoud, maar die eenvoud betekende geen SSH-toegang, geen mogelijkheid om de MySQL-configuratie direct aan te passen, en reactietijden van de support die in uren werden gemeten tijdens de eigen Black Friday-piek van hun provider. De instellingen voor PrestaShop-prestaties die we via de beheerconfiguratie konden aanpassen—caching, compilatie, debugmodus—stonden al correct. De database zelf was redelijk geoptimaliseerd; hun vorige ontwikkelaar had de gebruikelijke opschoonroutines ingevoerd. Het probleem zat in de infrastructuurlaag, in configuraties die hun hostingomgeving hen bewust niet liet wijzigen.

→ Wacht niet tot Black Friday om de grenzen van je infrastructuur te ontdekken

Onze noodinterventie verliep via twee parallelle sporen. Ten eerste implementeerden we direct verkeersbeheer om de databasebelasting te verminderen en tegelijkertijd zoveel mogelijk verkoopcapaciteit te behouden. Statische versies van cruciale productpagina's werden naar CDN-edgeservers overgezet, waardoor klanten belangrijke promotieartikelen konden bekijken, zelfs terwijl dynamische functionaliteit beperkt bleef. De winkelwagen- en afrekenfunctionaliteit kregen prioriteit door middel van aanvraagroutering die de beperkte databaseverbindingen richtte op conversiekritieke bewerkingen in plaats van op browsen. Beheerfuncties werden volledig geblokkeerd om te voorkomen dat medewerkers de verbindingen zouden gebruiken die nodig waren voor klantenaankopen. Dankzij deze maatregelen kon de webwinkel met een lagere capaciteit blijven functioneren – verre van ideaal, maar wel met omzet in plaats van alleen maar fouten.

Het tweede onderdeel richtte zich op de onderliggende oorzaken door middel van infrastructuuraanpassingen. In samenwerking met het noodteam van de hostingprovider hebben we tijdelijke configuratiewijzigingen doorgevoerd die het maximale aantal databaseverbindingen en PHP-workerprocessen verhoogden tot boven de standaardlimieten. De geheugentoewijzing voor PHP-processen werd uitgebreid om geheugenuitputting te voorkomen, wat had bijgedragen aan de kettingreactie van storingen. Aan het begin van de middag – ongeveer vier uur na de eerste storing – was de webwinkel weer volledig operationeel, met een tijdelijk aangepaste infrastructuur om het verkeer dat de promotie genereerde te verwerken. De verkoop hervatte, zij het in een lager tempo dan bij een volledige dag, maar herstelde wel een aanzienlijk deel van de omzet die aanvankelijk een volledig verlies leek te zijn.

De analyse achteraf liet infrastructuur zien die nooit goed was geschaald voor het verkeer dat het marketingteam kon genereren. Hun PrestaShop-hosting voldeed voor de normale dagelijkse werking en bescheiden actiepieken, maar grote campagnes draaiden op aannames over capaciteit die niemand met een belastingtest had gecontroleerd. De databaseverbindingslimiet van honderdvijftig ondersteunde bij hun querypatroon ongeveer honderd gelijktijdige bezoekers—ver onder de duizenden die een geslaagde Black Friday-campagne zou aantrekken. De geheugentoewijzing van hun hostingpakket kon het aantal PHP-workers niet dragen dat hoge gelijktijdigheid vraagt. Deze beperkingen bleven onzichtbaar tijdens de normale werking en kwamen pas catastrofaal aan het licht toen marketing precies slaagde op de schaal waar ze naartoe werkten.

De oplossing die we voor de volgende seizoenen invoerden, pakte deze kwetsbaarheden aan met een architectuur ontworpen voor piekcapaciteit in plaats van een basis die net voldoet. De database-infrastructuur werd gemigreerd naar dedicated MySQL-hosting met verbindingslimieten die pasten bij hun verkeersambities. Webservers kwamen achter loadbalancing te staan die tijdens actieperiodes horizontaal kon schalen. Redis-caching werd ingevoerd om het volume aan databasequery's met tachtig procent te verlagen, waardoor de effectieve capaciteit sterk toenam. Belastingtests bevestigden dat de nieuwe architectuur tienduizend gelijktijdige gebruikers aankon zonder verslechtering—capaciteit die zelfs wild succesvolle acties aankan zonder dat de infrastructuur de beperkende factor wordt.

Is uw winkel klaar voor de volgende grote kans?

De €40,000 aan verloren Black Friday-omzet die deze webwinkelier meemaakte, is slechts de direct meetbare schade—de omzet van bezoekers die tijdens die gecrashte uren probeerden te kopen. De niet gemeten kosten omvatten klantrelaties die beschadigd raakten door foutpagina's, merkreputatie die leed onder klachten op sociale media, en advertentiebudget dat verspild werd aan verkeer dat storingen kreeg in plaats van een winkelervaring. Elke PrestaShop-winkel die een grote actie plant, loopt hetzelfde risico als de infrastructuur niet is getoetst aan het verwachte piekverkeer. De vraag is niet of het je lukt verkeer aan te trekken—je marketingteam werkt precies naar dat resultaat toe. De vraag is of je infrastructuur dat verkeer omzet in verkopen of in een casestudy over wat er misgaat wanneer de voorbereiding de ambitie niet bijhoudt.

→ Toets je infrastructuur vóór je volgende campagne