Black Friday utan magont – problem att förutse och hur du undviker dem

Black Friday närmar sig

Black Friday avslöjar svagheter i integrationer. Det som “funkar okej” i vardagen brister när trafik och förändringstakt peakar. Här är de vanligaste problemen – och hur du designar bort dem med en plattform i Azure i stället för punkt-till-punkt-kopplingar.

1. Kampanjpriser som fastnar i batch-jobb

När priset ska växla 00:00 är “nattlig batch” för långsam. Feeds uppdateras sent, cachar lever gammalt, och Google/marknadsplatser visar fel.

Exempel

• 00:00 – priset sänks i ERP

• 00:02 – kunderna söker produkten

• 08:00 – Merchant Center/kanaler är ikapp – åtta timmar för sent

Konkurrenten har redan fångat nattens trafik.

Lösning i praktiken

• Publicera pris/kampanj som realtids-händelser via en kö (t.ex. Service Bus), inte som nattlig export.

• Sätt freshness-SLO för pris/kampanj (t.ex. ≤60 sek end-to-end) och larma på överträdelser.

• Använd feature flags för aktivering exakt 00:00 och canary (1–5 % trafik) minuterna innan skarpt släpp.

2. När lagret ljuger – översälj och returer

Stort inflöde + långsam återföring av saldo = kund kan lägga order på slut vara.

Exempel
En produkt med 100 kvar säljer 120 st första halvtimmen. Lageruppdateringens latenstid är >5 min. 20 kunder får backorder/avslag.

Lösning i praktiken

• Skicka lager som event vid varje förändring – undvik “poll var 5:e minut”.

• Använd reserv- eller kvot-modell i checkout (hårda eller mjuka reserver) för hot items.

• Definiera SLO för lagersynk (t.ex. ≤30 sek) och använd backpressure om ERP inte hänger med.

3. Dubbelordrar och webhook-stormar

Under peak dubblar användare klick, betalleverantör gör retry, marknadsplats skickar samma webhook flera gånger.

Exempel
Checkout får timeout, kunden klickar igen, PSP retrar – tre anrop skapar tre ordrar i ERP.

Lösning i praktiken

• Inför idempotensnyckel per order (lagras i plattformen). Samma nyckel = en order.

• Lägg API-perimeter (API Management) som kräver signatur, tidsfönster och idempotens-header.

• Hantera retries via dead-letter och exponential backoff + jitter i kölagret.

4. ERP i flaskhalsen – när systemet inte hänger med

Direkta anrop mot ERP slår i taket (rate limits/CPU). Utan köer förloras anrop eller checkout blockeras.

Exempel
ERP tål 100 req/min, peak kräver 800 req/min. Direktintegration time:outs → order/export faller bort.

Lösning i praktiken

• Frikoppla med kö (Service Bus). Ta emot i plattformens takt, processa i ERP:s takt.

• Dimensionera workers (Functions) för att beta av backlog efter peak – håll SLA i snitt.

• Sätt brownout-läge: icke-kritiska flöden parkeras, orderflöde prioriteras.

5. Prestanda i kanten – gateway, cache och skydd

Utan tydlig ytterkant blir både legitima toppar och attacker farliga.

Exempel
Plötslig trafikspik ger 429/500 i slumpmässiga flöden; fel går rakt igenom till backend.

Lösning i praktiken

• Använd API Management + Front Door/WAF som styr rate limits, geo/IP-policy, mTLS vid behov.

• Cacha ofarliga läsningar (t.ex. statiska attribut) och håll skrivvägen strikt och idempotent.

• Gör kapacitetsmodell: testa minst 3× vardagslast i lasttest före Black Friday.

6. Observability – från “det funkar inte” till konkret orsak

Utan korrelation vet du inte vilket steg som brast.

Exempel
“Orderexport nere” visar sig vara en ny partnerpayload som saknar ett attribut.

Lösning i praktiken

• Använd korrelations-ID genom hela kedjan (APIM → Functions → Service Bus → ERP).

• Bygg dashboards för tre SLO:er: Order-latens, Pris/Kampanj-freshness, Lager-freshness.

• Larma på dead-letters, signaturfel, ovanlig retry-frekvens, spike i 429.

7. Förändringar nära peak – utan att bryta

Sista-minuten-ändringar kan tippa hela systemet.

Exempel
Ny kampanjregel rullas ut brett 21:00 – PR glömde negativt kantfall.

Lösning i praktiken

• Använd feature flags + canary (1–5–20–100 %) med automatisk rollback på larm.

• Inför “change freeze” på icke-kritiska delar sju dagar före Black Friday.

• Kör konfiguration som kod med obligatoriska kontraktstester på partnerpayloads.

8. Säkerhet under peak

Trycket ökar inte bara från kunder.

Exempel
Läckta SAS-nycklar eller öppna funktionsendpoints underlättar scraping/DoS – precis när ni är mest sårbara.

Lösning i praktiken

• Använd Managed Identity överallt, Key Vault med rotation, privata endpoints.

• APIM-policies: signaturvalidering, ip/geo-filter, DDoS-skydd och bot-regelverk.

• Begränsa SAS: tidsbundet, IP-låst, minsta behörighet.

Tre mini-case (konkreta resultat)

• Kampanj 00:00: Bytte från batch till event-driven prisfeed + flaggstyrd aktivering. Freshness sjönk från ~4 h till <60 s. Intäkt första timmen +14 % YoY.

• ERP-flaskhals: Införde kö + workers, prioritering av order framför sekundära flöden. 0 % orderförlust, backlog ikapp på 17 min efter peak.

• Dublettordrar: Idempotensnyckel + APIM-signaturer. Dubletter ner 99,8 %, supportärenden per 1 000 ordrar halverades.

Black-Friday-playbook (kort och konkret)

• Sätt SLO:er: Order ≤ X sek, Pris/Kampanj-freshness ≤ Y sek, Lager-freshness ≤ Z sek.

• Testa: Lasttest 3× vardag, chaos på ERP-timeout och PSP-retry.

• Skydda kanten: APIM-rate-limits, signaturer, WAF/bot-skydd.

• Gör robust: Idempotens, köer, backoff + jitter, brownout-läge.

• Styr förändring: Feature flags, canary, change-freeze på icke-kritiska delar.

• Mät & larma: Korrelations-ID, dashboards för SLO:er, larm på dead-letters/429/signaturfel.

Slutsats

Black Friday är inte ett “mer av samma”. Det kräver realtid i pris/kampanj/lager, idempotens i order, köer mot tröga system, hård perimeter och mätbarhet i varje steg.

Bygger du detta som plattform i Azure – i stället för direktkoppling – får du kontroll när det gäller som mest: fler avslut, färre incidenter och en lugnare natt mellan 00:00 och 08:00.

Vill du börja enkelt? Ta pris/kampanj-flödet, sätt freshness-SLO, bygg event-väg, mät före/efter – och rulla vidare.