TL;DR: Brandøvelser hver anden måned hele året, der simulerer 150 % af sidste års BFCM-belastning. Test så massive, at vi kørte dem om natten og koordinerede med YouTube. Hver test afslørede flaskehalse – Kafka, hukommelse, timeouts – som vi rettet og revaliderede. Vi stoppede ikke, før infrastrukturen fungerede under ekstrem belastning.
Black Friday Cyber Monday (BFCM)-weekenden er den ultimative test af Shopifys infrastruktur. Millioner af handlende og titusindvis af købere er afhængige af os i løbet af årets fire største dage.
I 2024 slog vi flere præstationsrekorder57.3 PB data, 10.5 billioner databaseforespørgsler, 1.19 billioner edge-anmodninger og 1.17 billioner databaseskrivninger. Vi toppede med 284 millioner anmodninger pr. minut på edge og 80 millioner på app-servere, hvilket bragte os op på 12 TB pr. minut alene på Black Friday. Dette trafikniveau er bare en almindelig dag for Shopify.
Selvfølgelig bliver dette år endnu større. For at håndtere den kommende trafiktsunami har vi genopbygget vores BFCM-beredskabsprogram fra bunden.
Benjamin Franklin sagde engang: "Ved at undlade at forberede sig, forbereder man sig på at fejle." Sådan har vi forberedt os hele året på at få succes i Super Bowl.
Opbygning af modstandsdygtighed året rundt
Vores forberedelse til BFCM startede i marts med kapacitetsplanlægning og en strategi for flere regioner på Google Cloud. Pålidelighed er et arbejde, der skal udføres året rundt. Vi bruger ikke BFCM som en frigivelsesfrist – enhver arkitekturændring og migrering sker måneder før det kritiske vindue.
Tre parallelle arbejdsgange kører samtidigt under vores forberedelse:
-
KapacitetsplanlægningVi modellerer trafikmønstre ud fra historiske data og vækst i forhandlere og sender vores estimater til vores cloududbydere, så de ikke løber tør for cloud. Denne planlægning definerer, hvor meget infrastruktur vi har brug for, og hvor vi har brug for den geografisk.
- InfrastrukturkøreplanVi gennemgår vores teknologiske stak, evaluerer arkitektoniske ændringer og identificerer opgraderinger til målkapaciteten. Dette hjælper os med at koordinere det kommende arbejde.
- Risikovurderinger: What Could Go Wrong (WCGW) øvelser dokumenterer fejlscenarier, fastsætter eskaleringsprioriteter og genererer input til Game Day. Med disse oplysninger tester og hærder vi vores systemer på forhånd.
Hvert spor påvirker de andre. Risikoanalyser kan afsløre kapacitetsmangler, ændringer i infrastrukturen kan introducere nye risici osv.
Spilledage
For at vurdere risici lænede vi os kraftigt op ad Game Days: kaosteknikøvelser, der simulerer produktionsfejl på BFCM-skala.
Vi begyndte at afholde Game Days i det tidlige forår. Vi injicerede bevidst fejl i vores systemer for at teste, hvordan de reagerede under fejlforhold, og om de validerede vores hændelsesrespons. Vi brugte ekstra tid på de mest forretningskritiske brugerstier gennem Shopify, såsom betaling ved betaling, ordreoprettelse og ordreopfyldelse – kalder vi disse "kritiske rejser".
Critical Journey Game Days kørte katastrofesimuleringer på tværs af systemer, testede søge- og sideslutpunkter, randomiserede navigation for at efterligne rigtige brugere, injicerede netværksfejl og latenstid samt cache-busting for at skabe realistiske belastningsmønstre. Frontend-teams kørte bug bashes for at identificere regressioner, teste kritiske brugerflows og validere brugeroplevelse under spidsbelastningsforhold.
Disse øvelser opbyggede muskelhukommelse til vores håndtering af hændelser og afdækkede huller i vores handleplaner og overvågningsværktøjer. Vi lukkede disse huller længe før BFCM.
Alle resultater indgår i vores robusthedsmatrix: en centraliseret dokumentation af sårbarheder, procedurer for hændelsesrespons og rettelser.
Modstandsdygtighedsmatricen
Matricen fungerer nu som vores køreplan for systemhærdning inden BFCM. Teams opdaterer matricen løbende i løbet af året og dokumenterer vores robusthed på tværs af Shopify. Matricen inkluderer:
- Servicestatus: Nuværende driftstilstand for alle kritiske tjenester
- Fejlscenarier: Dokumenterede fejltilstande med konsekvensanalyse
- Gendannelsesprocedurer: Forventede mål for restitutionstid (RTO'er) og detaljerede runbooks
- Operationelle handlingsplaner: Trinvise vejledninger til håndtering af hændelser
- Dækning på vagt: Teamplaner og PagerDuty-eskaleringsruter for at sikre hurtig respons på hændelser
Belastningstest
Vi kan ikke vente til BFCM opdager vores kapacitetsgrænser, så vi bruger load test til at simulere den trafik på forhånd. Dette giver os mulighed for at finde vores brudpunkter måneder i forvejen og giver vores teams tid til at skalere infrastrukturen og optimere koden i overensstemmelse hermed.
Vores load test-værktøj, Genghis, kører scriptede arbejdsgange, der efterligner brugeradfærd som browsing, tilføjelse af indkøbskurve og betaling. Vi øger gradvist trafikken for at finde brudpunkter. Test kører samtidigt på produktionsinfrastrukturen fra tre GCP-regioner (US-Central, US-East og Europe-West4) for at simulere globale trafikmønstre. Vi injicerer flash-salgsudbrud oven i baseline-belastningen for at teste spidsbelastningskapaciteten.
Toksikrilt, et open source-framework, vi har bygget til simulering af netværksforhold, indsætter netværksfejl og partitioner (hvor tjenester ikke kan nå hinanden). Vi overvåger dashboards i realtid og er klar til at afbryde, hvis systemerne forringes. Flere teams koordinerer for at finde og løse flaskehalse.
Når vi rammer grænserne, har holdene tre muligheder:
- Horisontal skalering: flere forekomster
- Lodret skalering: flere ressourcer pr. instans
- Optimeringerændringer i arkitekturlaget, der forbedrer ydeevnen
Optimeringer spænder fra forbedringer af forespørgsler på databaseniveau til performancejustering på tværs af forbrugerlag og helt op til frontend. Disse beslutninger fastsætter den endelige BFCM-kapacitet og driver optimeringsarbejdet på tværs af vores stak.
Nye analytiske udfordringer
BFCM tester alle systemer hos Shopify, men 2025 præsenterer en unik udfordring: En del af vores infrastruktur har aldrig oplevet juletrafik. Hvordan forbereder I jer på spidsbelastning, når I ikke har historiske data at modellere ud fra?
I 2024 genopbyggede vores team analyseplatformen, skabte nye ETL-pipelines (Extract, Load, Transform), skiftede persistenslag og erstattede vores ældre system med nye API'er. Migreringen blev rullet ud i løbet af året.
Dette skabte en asymmetri. Vores ETL-pipelines løb gennem BFCM 2024, hvilket betyder, at vi har én sæson med produktionsdata. Men vores API-lag blev lanceret efter højsæsonen. Vi forbereder os på BFCM på API'er, der aldrig har set ferietrafik.
Vores analyseinfrastruktur afspejler Shopifys bredere arkitektur: uafhængige tjenester, der håndterer intensive rapporter, aggregeringer og realtidsbehandling. Vi kørte også Game Days her: kontrollerede eksperimenter designet til at afsløre fejltilstande og flaskehalse. Vi simulerede øgede trafikbelastninger, introducerede databaselatens og testede cache-fejl – systematisk kortlægning af systemadfærd under stress.
Resultaterne viste, at vores ETL-pipelines havde brug for øgede Kafka-partitioner for at opretholde datafriskhed under spikes. API-lagets hukommelsesforbrug krævede optimering, hvilket blev fundet gennem profilering. Forbindelsestimeouts skulle justeres for at forhindre pool-udtømning. Vi aflastede anmodninger, der gik til en anden region, via en anden load balancer-tilgang for at købe ekstra pusterum. Ud over ydeevnerettelser validerede vi alarmeringer og dokumenterede responsprocedurer. Som et resultat er vores teams trænet og forberedt på at håndtere og reagere under fejl.
BFCM 2025 bliver den ultimative test, hvor vores API'er bliver ramt af hidtil uset juletrafik. Vi har tacklet alle kendte flaskehalse og er forberedte på at håndtere det ukendte.
Programmet for skalatestning
Spildage og belastningstest forbereder os, men de tester komponenter isoleret. Skalatestning er anderledes – det validerer hele platformen, når den arbejder sammen ved BFCM-volumener, og afslører problemer, der kun dukker op, når alt kører på fuld kapacitet samtidigt.
Fra april til oktober kørte vi fem større tests med forventede trafikniveauer, vores antagelser om maksimal p90-trafik. De to første tests validerede baseline-ydeevnen i forhold til 2024-ydeevnen. Test tre til fem blev øget til 2025-prognoser. Ved den fjerde test nåede vi 146 millioner anmodninger pr. minut og over 80,000 checkouts pr. minut. På årets sidste test testede vi p99, som var 200 millioner RPM.
Disse tests er så store, at vi er nødt til at køre dem om natten og koordinere med YouTube. Vi testede robusthed, ikke kun indlæsning. Vi udførte regionale failovers, hvor vi evakuerede trafik fra centrale regioner i USA og EU for at validere katastrofeberedskab.
Vi kørte flere tests:
- Arkitekturopskalering: Bekræftet, at vores infrastruktur håndterer planlagt kapacitet
- Belastningstest (normal drift): Etableret baseline-ydeevne ved spidsbelastning
- Indlæsningstests (med failover): Valideret disaster recovery og cross-regional failover
- Simulationer på kampdagen: Testet tværsystemrobusthed gennem kaosteknik
Vi simulerede reel brugeradfærd: browsing i butik og betaling, admin API-trafik fra apps og integrationer, analyser og rapportering belastninger og backend webhook-behandling. Vi testede også kritiske scenarier: spidsbelastning, regional failover og kaskadefejl, hvor flere systemer fejler samtidigt.
Hver testcyklus identificerede problemer, vi aldrig ville se under stationær belastning, og vi løste hvert problem, efterhånden som det opstod.
- Skalatest 1-2: Under tung belastning skabte kerneoperationerne fejl, og der opstod køer i kassen.
- Skalatest 3: Validerede nøglemigreringer og bekræftet regional routing fungerer som forventet efter ændringer.
- Skalatest 4: Hitgrænser, der udløste uplanlagt failover. Identificerede prioritetsproblemer i testtrafikrouting og opdagede forsinkelser ved tilbagesendelse af regioner online under rebalancering.
- Skalatest 5: Udførte fuld generalprøve, den eneste testkørsel i NA's åbningstid for at simulere reelle BFCM-forhold (resten foregik om natten).
- Midtprogramskift: Tilføjede autentificeret betaling til testscenarier. Modellering af rigtige købere eksponerede prisgrænsestier, der anonym browsing rører aldrig. Selv som en lille procentdel af trafikken afslørede autentificerede flows flaskehalse.
Skaleringstest er en holdsport. Infrastruktur skalerer platformen og overvåger tilstanden, produktteams validerer funktioner under belastning, SRE forbereder incidentrespons, og support forbereder spørgsmål fra forhandlere. Vi koordinerer også disse tests tæt med vores cloud- og CDN-udbydere.
BFCM's operationelle plan
BFCM-forberedelse gør os klar, og operationel ekspertise holder os stabile, når trafikken stiger. Vores operationelle plan koordinerer ingeniørteams, hændelsesrespons og live systemjustering.
Vores operationelle plan for BFCM-weekenden inkluderer:
- Realtidsovervågning: Dashboard-synlighed på tværs af alle regioner med automatiserede advarsler
- Hændelsessvar: Incident Manager OnCall (IMOC)-teams med dækning og eskaleringsruter døgnet rundt
- Forhandlerkommunikation: Statusopdateringer og meddelelser
- Liveoptimering: Systemjustering baseret på trafikmønstre i realtid
- Debriefing efter BFCM: Korrelation af overvågningsdata med resultater fra forhandlere
Det er den mest vidunderlige tid på året
Tusindvis af ingeniører. Ni måneder. Fem skalaforsøg. Fire dage med højeste handelsbelastning og én solid platform klar til at håndtere det hele.
Vores beredskabsprogram for 2025 var intensivt. Vi udførte regionale failovers, kørte kaosteknikøvelser, dokumenterede systemsårbarheder og forstærkede systemer med opdaterede runbooks, før vores handlende havde brug for dem.
Som en bonus er de værktøjer, vi har bygget, ikke midlertidige BFCM-stilladser. Resiliency Matrix, Critical Journey Game Days og adaptiv prognose i realtid er permanente infrastrukturforbedringer. De gør Shopify mere robust hver dag, ikke kun i højsæsonen.
BFCM starter den 28. november. Vi er klar. 🚀
Hvis du er interesseret i at deltage i vores mission om at gøre handel bedre for alle, så tjek vores karrierer side.
Kyle Petroski er en teknisk leder i analyseteamet.
Matthew Frail er en teknisk programleder i teamet for ingeniørdrift.
