Black Friday voorbereidingen — loadtest en scaling checklist

Black Friday voorbereidingen — loadtest en scaling checklist

Vorig jaar crashte een bekende Nederlandse webshop om 00:01 uur op Black Friday. 40.000 bezoekers tegelijk, een server die niet was voorbereid, en drie uur downtime. Omzetschade: reken op vijf- tot zescijferige bedragen in zo'n nachtvenster. Dit is geen horror story om indruk te maken — het is een patroon dat we elk jaar zien terugkomen.

Black Friday is geen normale piekdag. Het verkeer is voorspelbaar in timing maar onvoorspelbaar in volume. De enige manier om er goed doorheen te komen, is voorbereiding. Loadtesten, schalen, en een draaiboek klaar hebben liggen voor als het toch misgaat. Hier is de checklist.

1. Baseline meten voor je begint

Zonder baseline weet je niet of je verbeteringen effect hebben. Verzamel eerst:

• Gemiddeld aantal pageviews per uur op een normale dag
• Piekuren van vorig jaar (Google Analytics / server logs)
• Gemiddelde responstijd van je checkout, categoriepagina, en homepage
• Database query-tijd per endpoint (slow query log aanzetten)

In de praktijk zien we bij Magento 2-shops dat de checkout-flow en de categoriepagina met filters het eerste vastlopen. Die twee endpoints zijn je primaire doelwit.

2. Load testing: k6 of Gatling?

Loadtesten doe je minimaal vier weken voor Black Friday. Dan heb je nog tijd om bottlenecks op te lossen en opnieuw te testen.

// k6 basis load test — productpagina + checkout flow
import http from 'k6/http';
import { sleep, check } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },   // ramp-up naar 100 gebruikers
    { duration: '5m', target: 500 },   // Black Friday volume
    { duration: '2m', target: 1000 },  // worst-case scenario
    { duration: '2m', target: 0 },     // ramp-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<2000'],  // 95% van requests < 2 seconden
    http_req_failed: ['rate<0.01'],     // minder dan 1% errors
  },
};

export default function () {
  const res = http.get('https://jouwshop.nl/categorie/aanbiedingen');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);

  const cart = http.post('https://jouwshop.nl/checkout/cart/add', {
    product_id: '123',
    qty: '1',
  });
  check(cart, { 'cart ok': (r) => r.status === 200 });
  sleep(2);
}

Test altijd op een acceptatie-omgeving die zo dicht mogelijk bij productie staat. Een testomgeving met 1/4 van het productie-geheugen geeft geen betrouwbare resultaten.

3. Autoscaling: horizontaal schalen voor piekverkeer

Een vaste serverconfiguratie is voor Black Friday de verkeerde keuze. Je betaalt het hele jaar voor overcapaciteit, of je zit met te weinig op de piekdag zelf.

Op DigitalOcean, AWS, of Hetzner stel je autoscaling in op basis van CPU-gebruik of request count. Praktische richtlijnen:

• Trigger autoscaling bij 60-70% CPU, niet bij 90%. Bij 90% is het al te laat.
• Zorg dat je AMI/snapshot klaar staat en een nieuwe instance in minder dan 90 seconden live is.
• Test de autoscaling zelf — start een loadtest en kijk of nieuwe instances daadwerkelijk aangehaakt worden.
• Stel een maximum in op je scaling group. Anders loop je het risico op een onverwachte cloudrekening van duizenden euro's.

Bij Magento specifiek: de admin-backend en de frontend moeten op aparte instances draaien. Een dump-import via de admin tijdens piekverkeer kan je hele frontend platleggen.

4. Cache-strategie: Varnish, Redis, en CDN

Cache is de goedkoopste performance-winst die er is. Een pagina die niet gegenereerd hoeft te worden, kost geen servercapaciteit.

• Zijn je cache hit rates boven de 80%? Zo niet, dan is er een probleem met cache-invalidatie of te veel unieke URLs.
• Zijn pagina's met sessie/cookie (ingelogde gebruikers, cart) correct uitgesloten van full-page cache?
• Is je Varnish TTL realistisch voor Black Friday? Kortere TTL = meer cache misses. Zet hem voor statische contentpagina's op minimaal 1 uur.

Controleer je cache-headers voor Black Friday:

curl -I https://jouwshop.nl/categorie/sale | grep -i cache
# Verwacht: Cache-Control: public, max-age=3600
# Probleem: Cache-Control: no-cache, no-store (alles gaat door naar origin)

5. Database-bottlenecks opsporen

De database is in de meeste gevallen het eerste knelpunt. Geen hoeveelheid horizontaal schalen van je application layer helpt als je database vastloopt.

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; -- queries boven 1 seconde loggen
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Analyseer de output met pt-query-digest (Percona Toolkit). Dit geeft je de top-10 traagste queries inclusief hoe vaak ze voorkomen.

Veelvoorkomende bottlenecks bij e-commerce:

• Ontbrekende indexen op product_id, category_id, customer_id in join-queries
• N+1 queries — een lijstpagina die per product een extra query doet
• Voorraadupdates die tabelsloten veroorzaken tijdens hoge load
• Sessietabel die explosief groeit bij piekverkeer (overweeg Redis voor sessies)

Voor Shopify-shops is de database buiten je eigen beheer, maar controleer wel third-party app queries via de API. Apps die polling doen op je order-endpoint met hoge frequentie kunnen je API rate limits raken.

Read replicas zijn een optie als je reads en writes kunt scheiden. Wees eerlijk over wanneer dit de moeite waard is: voor de meeste shops onder de 500.000 producten is een goed geconfigureerde primaire database met de juiste indexen voldoende.

6. Queue-capaciteit: orders verwerken onder load

Een checkout die werkt is stap één. De verwerkingsketen erachter is stap twee. Orders die binnenkomen moeten via queues verwerkt worden: bevestigingsmail, voorraadupdate, ERP-koppeling, factuurgenerate.

Als je queue workers niet schalen met het ordervolume, loopt de queue vol. Klanten krijgen geen bevestigingsmail, je ERP loopt achter, en je support-inbox ontploft.

Controleer voor Black Friday:

• Hoeveel queue workers draaien er? Zijn die voldoende voor 3-5x normaal ordervolume?
• Wat is de priority van kritische jobs (bevestigingsmail) versus niet-kritische jobs (nieuwsbriefaanmelding)?
• Wat is je retry-strategie bij een failed job? Hoeveel pogingen, met welk backoff-interval?
• Wat gebeurt er als je e-mailprovider (Mailgun, Postmark) een rate limit treft?

Bij Laravel-backends gebruiken we Horizon voor queue monitoring. Horizon geeft realtime inzicht in job throughput, failed jobs, en wachttijden. Stel alerts in op failed job rates voor je het nodig hebt.

// config/horizon.php — aparte queue voor kritische jobs
'environments' => [
    'production' => [
        'supervisor-critical' => [
            'queue' => ['critical', 'default'],
            'processes' => 10,  // verdubbel dit voor Black Friday
            'balance' => 'auto',
        ],
        'supervisor-low' => [
            'queue' => ['low', 'notifications'],
            'processes' => 3,
        ],
    ],
],

7. Feature freeze: wat je NIET moet doen voor Black Friday

Minstens twee weken voor Black Friday geen grote deploys meer. Dit is de regel die het vaakst wordt genegeerd en het vaakst schade veroorzaakt.

Een nieuwe checkout-flow, een herschreven zoekmodule, of een major Magento-update hoort niet in de twee weken voor Black Friday. De kans op onverwachte bugs onder hoge load is te groot.

Wat nog wel mag:

• Hotfixes voor bekende bugs
• Configuratiewijzigingen (cacheregels, CDN-instellingen)
• Content-updates (banners, prijzen, kortingscodes)
• Monitoring en alerting aanscherpen

Wat niet meer mag:

• Nieuwe betaalmethoden of integraties live zetten
• Database-migraties uitvoeren
• Third-party apps updaten of toevoegen
• Infrastructure-wijzigingen die niet getest zijn

8. Draaiboek voor de piekdag

Een draaiboek is geen overkill. Het is de reden dat je om 02:00 uur 's nachts rustig kunt slapen, of snel handelt als er toch iets misgaat.

• Varnish cache warmen met een crawler (Screaming Frog of eigen script)
• Database vacuüm/optimize uitvoeren
• Alle monitoring-alerts controleren
• Contactinfo van hosting-support en kritische leveranciers klaar hebben
• Rollback-procedure documenteren

• Extra ogen op dashboards: New Relic, Datadog, of Grafana
• Response time en error rate elke 15 minuten checken de eerste twee uur
• Queue depth monitoren — loopt die op, dan workers bijzetten
• War room (Slack-kanaal of call) klaar met iedereen die kan handelen

1. Verhoogde response time → cache check, queue check
2. 5xx errors → application logs, recent deploys terugdraaien
3. Database vastgelopen → slow query log, connecties droppen
4. Volledige downtime → maintenance mode aan, hosting bellen, rollback

Documenteer dit draaiboek en deel het met iedereen in het team. Een draaiboek dat alleen in het hoofd van één persoon zit, is geen draaiboek.

Klaar voor Black Friday?

Een goede voorbereiding kost twee tot vier weken werk. Dat klinkt als veel, maar vergeleken met de omzetschade van drie uur downtime is het niets. Wij helpen bij loadtesting, scaling-architectuur en het opzetten van monitoring voor shops op Magento, Shopify en Laravel.

Neem contact op als je dit jaar voor het eerst serieus wilt voorbereiden, of als je vorig jaar een pijnlijke piekdag hebt gehad.

Veelgestelde vragen

Start minimaal zes weken voor Black Friday. Vier weken om te testen en bottlenecks op te lossen, twee weken feature freeze. Te laat starten betekent dat je gevonden problemen niet meer kunt oplossen zonder risico.

Ja. Je infrastructuur, productcatalogus, en verkeersvolume veranderen elk jaar. Een shop die vorig jaar 2.000 gelijktijdige gebruikers aankon, hoeft dat dit jaar niet meer te kunnen als er nieuwe apps, modules, of features zijn toegevoegd.

Neem je piekmoment van vorig jaar en vermenigvuldig dat met 1,5 tot 2. Als je vorig jaar op het drukste moment 800 gelijktijdige gebruikers had, test je op 1.200 tot 1.600. Zo bouw je buffer in voor groei.

Shopify schaalt automatisch mee. Jouw aandachtspunten zijn anders: third-party apps die traag worden of API rate limits raken, checkout-apps die niet getest zijn onder load, en externe koppelingen (ERP, warehouse) die het volume niet aankunnen. Test die ketens, niet de Shopify-infrastructuur zelf.