Blixtförsäljning och biljettsläpp: hantering av 10-trafik på ett elegant sätt
En flash försäljning är en trafik spik med ett stoppur på det - och ett andra problem mest skalning råd ignorerar helt: det finns bara så mycket lager, och alla vill ha det på samma ögonblick.
En flashförsäljning ser ut som en mindre svart fredag, och att förbereda sig för det som om det var en är hur droppar går fel.
Black Friday är ett kapåståendetta hälften. Den svåra halvan är att din inventering är ett litet antal som många samtidiga processer alla försöker minska, och varje sekund av försäljningen är en tävling.
Så detta är organiserat kring de tre problemen i den ordning de kommer att skada dig.
Problem 1: Alla kommer på en gång
Den goda nyheten är att det här är den del du redan vet hur man löser, och mycket av den ankommande trafiken begär identiska saker. Landningssidan, nedräkningen, produktbilderna, CSS - alla samma för alla, alla cacheable, alla servable från kanten utan att ditt ursprung märker.
Två detaljer är viktiga för droppar i synnerhet. Värm cachen innan meddelandet, eftersom en kall cache vid tidpunkten för en samordnad ankomst innebär tusentals samtidiga missar alla stämplat ditt ursprung för samma sida. Och se till att ditt CDN kollapsar samtidiga missar för samma objekt i en enda ursprungsbegäran, snarare än att vidarebefordra dem alla - det här beteendet går med flera namn, men dess frånvaro är exakt felet som tar ett ursprung nere vid T-noll.
Uppfriskande beteende är också värt att planera för. I minuten före en droppe trycker en stor del av dina besökare på F5 upprepade gånger. En nedräkningssida som är helt cachad absorberar detta. En nedräkningssida som frågar efter databasen för aktuell servertid gör det inte.
Problem 2: lager är ett nummer och alla vill ha det
Detta är den del som skiljer droppar från alla andra trafikhändelser, och det är inte ett cacheproblem alls.
När 5 000 personer klickar på "köp" på 200 enheter inom samma sekund måste ditt system bestämma vem som får dem. Gör det slarvigt och du översäljer - du tar 400 beställningar för 200 artiklar och spenderar följande vecka med att avbryta hälften av dem, återbetala och be om ursäkt. Gör det för försiktigt och du serialiserar hela försäljningen bakom ett enda lås, och alla väntar.
- Decrementera lagret atomiskt i databasen. En villkorlig uppdatering som bara lyckas när lagret finns kvar är säker. Läs-och-skriv-i-programkoden är det inte, oavsett hur snabbt det ser ut.
- Reservera vid tillägg till kundvagnen, inte vid betalning. Med en kort utgångstid. Annars säljer du samma enhet till alla som når kassan, och förlorarna får reda på betalningssteget, vilket är det värsta möjliga ögonblicket.
- Visa inte antalet levande lager på en cachad sida. Antingen utelämna dem eller ladda dem separat. En cachad "3 kvar" som faktiskt är noll genererar mer support e-post än inget nummer alls.
- Bestäm din överförsäljningspolicy i förväg. Vissa företag accepterar en liten överförsäljning och hedrar den; vissa gör det aldrig. Antingen är försvarbart. Att upptäcka att du inte har någon policy vid 20:01 är inte.
- Tak antal per beställning och per konto. Enkelt, och det gör mer mot återförsäljare än de flesta botdetektering.
Problem 3: En meningsfull del av publiken är inte mänsklig
Begränsade lagerdroppar lockar automatiserade köpare, och de är bra på detta. Ett skript kan slutföra kassan på en bråkdel av den tid en person behöver för att skriva ett kortnummer, och de personer som kör dem gör det professionellt.
Om du inte gör något, är den ärliga beskrivningen av en droppe som säljer ut på elva sekunder inte att efterfrågan var extraordinär. Det är att bots köpte ditt lager för att sälja det, dina faktiska kunder fick ingenting, och den goodwill du byggde gick till en andrahandsmarknad istället.
Vad fungerar, i syfte att effektivitet för ansträngningen:
| Åtgärd | Effekt | Kostnad för riktiga kunder |
|---|---|---|
| Kvantitetstak per konto och betalningsmetod | Hög | Ingen |
| Utmaning för bevis på arbete i tillägg till kundvagnen och i kassan | Hög | Millisekunder |
| Rategränser på inköpsendpoints | Hög | Ingen om den sätts förnuftigt |
| Kräv ett konto som skapats före släppet | Mycket hög | Utesluter nya kunder |
| Randomiserad köposition snarare än strikt ankomstorder | Måttlig | Känns mindre rättvist mot tidiga ankomster |
| CAPTCHA vid kassan | Lägre - lösa tjänster är billiga | Hög friktion |
Se upp för droppen som köps innan den öppnas. Bots hittar rutinmässigt produktwebbadresser och API-slutpunkter före den angivna tiden genom att gissa URL-mönster eller titta på din webbplatskarta. Om produktsidan finns klockan 19:55 och slutpunkten för tillägg till vagnen fungerar, började försäljningen klockan 19:55 oavsett vad nedräkningen säger.
Att sätta ihop de tre
Arkitekturen som håller är skiktad, och varje lager skyddar den bakom den:
Edge cache absorberar ankomsten
Landningssida, nedräkning, bilder och tillgångar serveras helt från kanten, uppvärmda i förväg, med samtidiga missar kollapsade.
Ett väntrum mäter flödet
Erkänn köpare i den takt som din kassa verkligen kan upprätthålla, snarare än att låta dem kollidera med den samtidigt.
Utmaningar och begränsningar filtrerar inköpsvägen
Gränser för hur mycket du kan lägga till i kundvagnen och hur mycket du kan betala för i kassan, vilket innebär att automatiserad volym blir oekonomisk.
Databasen arbitrerar beståndet atomiskt
Villkorliga minskningar, kortlivade reservationer och en mängdtak. Detta är sista raden och den måste vara korrekt.
Observera att endast det sista lagret måste vara exakt rätt. De tre första finns för att minska hur mycket belastning och hur mycket motstridiga trafik når det - vilket är den allmänna principen bakom allt detta, och orsaken droppar är överlevande alls.
Efteråt
Skriv ner det medan det är färskt: hur länge lagret varade, hur många beställningar avbröts, hur kön såg ut, vad som bröt, vad du blev förvånad över. Droppar återkommer, ofta med samma kunder och samma bots, och den andra är enormt lugnare om någon skrev en sida med anteckningar efter den första.
Vanliga frågor
Hur förhindrar jag att min webbplats kraschar under en flashförsäljning?
Cache allt som är identiskt för alla besökare - målsida, nedräkning, bilder och tillgångar - och värma den cachen innan du meddelar, så den samordnade ankomsten producerar inte tusentals samtidiga cache Missar. Sätt ett väntrum framför dig så att köparna kan betala med en hastighet som de klarar och begränsa köpets slutpunkter. Den omöjliga utcheckningsvägen är det som misslyckas, så målet är att kontrollera hur mycket trafik som når den.
Hur förhindrar jag överförsäljning under en begränsad lagerminskning?
Decrement lager atomärt i databasen med hjälp av en villkorlig uppdatering som bara lyckas medan enheter kvar, snarare än att läsa lager och sedan skriva in programkod, som tävlingar under samtidighet. Reservera lager på add-to-cart med en kort utgång i stället för vid betalning, så att kunderna inte upptäcker vid betalningssteget att deras produkt är borta. Sätt ett tak per order och per konto, och bestäm din policy för överförsäljning före försäljningen snarare än under den.
Hur stoppar jag robotar från att köpa alla mina begränsade lager?
Kvantitetstak per konto och betalningsmetod är det mest effektiva måttet för minsta möjliga friktion. Lägg till hastighetsgränser och en proof-of-work-utmaning på add-to-cart och kassan, vilket kostar en riktig webbläsare millisekunder och gör automatiserad volym oekonomisk. CAPTCHA är i stort sett ineffektiva här, eftersom lösningstjänster är billiga och återförsäljare använder dem rutinmässigt. Bekräfta också att produktens webbadress och inköpsslutpunkt inte kan nås före den angivna starttiden.
Bör jag visa live lagernivåer under en droppe?
Inte på en cachad sida. En cachad sida som visar "3 återstående" när den sanna siffran är noll ger mer kund frustration än att visa inget nummer alls. Antingen utelämna lagerräkningar från cachade sidor, eller ladda dem genom en separat ocachad begäran som kan vara hastighetsbegränsad oberoende, acceptera den extra ursprungsbelastningen som skapar.
Vad är skillnaden mellan att förbereda sig för Black Friday och en flash-försäljning?
Black Friday är i första hand ett kapacitetsproblem – fler besökare än vanligt, fördelade över timmar, köp över en bred katalog. En droppe är ett problem: många människor tävlar om en liten, fast mängd på några sekunder. Det lägger till oro Black Friday har inte, särskilt atomär lagerhantering för att förhindra överförsäljning och försvar mot återförsäljningsrobotar, utöver den trafikhantering som båda händelserna kräver.
Design för koncentration och strid, inte bara volym, och en droppe blir en krävande sextio sekunder snarare än en dålig kväll.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
