Sale day bot spikes: preparing a store for launch traffic that is half human, half automated

Know which pages and actions will be hit

Map the launch surface in advance: the product page, size or variant selection, cart add, queue or waiting room, checkout start, and any stock or price endpoints behind them. Bots concentrate where scarcity is decided, usually add to cart and checkout, while humans spread across browsing. Capacity and protection should follow that map, not be spread evenly across the whole site like butter.

Decide the fairness rules before launch day, in writing: per customer quantity limits, whether carts reserve stock and for how long, how the queue orders arrivals, and what happens to suspicious sessions. Rules invented mid spike, under social media pressure, are inconsistent and leak. Rules published calmly in advance can be enforced by systems instead of by exhausted staff.

Make the queue and limits do the heavy lifting

A waiting room that admits shoppers at the rate the store can actually serve converts a stampede into a line, and a line with honest position information produces far fewer retries than a failing page. Pair it with server side quantity and velocity limits per account, device, and payment instrument, enforced at cart and checkout, not merely displayed in the page where a bot can ignore them.

Cart hold policy is a fairness dial. Long holds let bots park scarce stock while they arrange resale. Short holds frustrate slow humans on bad connections. Most launches do better with a clear, stated hold that starts at checkout rather than at cart add, plus automatic release that actually runs during the spike. Test the release job under load, not just the happy path.

Load test with an adversary in mind

A clean load test with well behaved virtual shoppers proves the store handles fans. It says nothing about refresh storms, queue polling, and automated add to cart attempts arriving together. Add hostile patterns to the test: aggressive refreshing, many sessions per identity, and endpoint probing. Watch the metrics that degrade first, usually database writes around stock and cart, and fix the earliest bottleneck rather than the most visible one.

Prepare the boring artefacts too: a status message ready to publish, support macros for the predictable questions, a decision log template, and a named person empowered to pause the launch. Launches rarely fail for lack of effort. They fail when a known problem needs a decision and nobody in the room owns it, while the queue grows and the bots keep their places.

Review the hour while it is still honest

After the launch, review within days: how much traffic was automated by best estimate, where limits triggered, how many real customers were caught by controls, and which fairness rules bent. Feed the findings into the next launch checklist while memories are specific. Teams that skip this review repeat the same launch twice a year and call the pattern tradition.

Share a fair summary publicly when the launch was contested: what was sold, what protections ran, what will change. Fans accept scarcity. They do not accept the suspicion that the game was rigged by software they cannot run. A store that explains its fairness work earns the benefit of the doubt next time, which on launch day is worth more than any single control.

Keep reading: API abuse bots: why your mobile and checkout APIs get attacked even when the website looks fine, Inventory hoarding bots: how automated carts lock up stock real shoppers cannot buy, and Credential stuffing attacks on retail accounts: borrowed passwords at machine speed cover the nearby cases in this series.

Frequently asked questions