Last summer, a single 24-hour Shopify launch sold 2,917,443 copies of a book. That more than doubled the previous record for the fastest-selling nonfiction title in history. By the end of the launch window, the merchant had moved 3.6 million copies and $106 million in sales.
On a recent internal call about that project, our lead engineer on the launch, Alex, slid a photo across the screen. It was a certificate. Embossed seal in the corner. “World Record” with a hologram effect. His first name front and center.
The certificate is a nice artifact. The real story is what had to be built, tested, and measured months in advance so the infrastructure behind that launch didn’t buckle when the traffic actually hit. Here’s what that looked like, with the numbers our engineering team pulled after the fact.
Split the stack by what each piece is good at
Months before launch day, the engineering question was simple. Can MESA handle a sustained, livestream-driven spike that nobody could size in advance?
We started by mapping what each piece of the stack needed to do.
Shopify receives the orders. That’s its job, and it delivers them through webhooks even if it takes a beat. Mailgun sends the emails. That’s its job too, and it has deliverability rules you have to respect. The part in the middle has to catch every order, mint a unique discount code, queue the email, track whether it landed, retry failures, and write every step back to a ledger. Under load. Under timing pressure. Without dropping a row.
That part is MESA.
Most platforms in our category will tell you they can be the part in the middle. The difference shows up under load, not on a feature comparison page.
Load testing and capacity planning before day one
Here’s what the team actually did in the months before launch.
We mapped the workflows, drew up a timeline, and identified the levers that would need adjusting before go-time. Parallel worker entitlements. Queue depths. Rate limits.
Then we ran a stress test against the live data table to measure throughput without actually sending actions. The pace it could sustain under test was the pace we could plan around. That was the basis for the capacity numbers, not a guess.
An on-call rotation covered every subsystem we suspected might bind, with documented handoffs and monitored dashboards. The week before, we raised capacity on every axis that had a ceiling.
Edge cases got worked out ahead of time too. What happens if a customer refunds the order? What happens if a recipient’s email bounces? Each became its own workflow before the countdown started.
- Peak minute: 66,740 books sold per minute at 5:52pm UTC, Aug 16
- Sustained hour: 1,102,264 books between 5:00pm and 6:00pm UTC, averaging 18,400 books sold per minute for a full hour
- Completion rate: 99.9% during the live 24 hours
The same infrastructure, repurposed
In the months since, the same tables and workflows set up for the launch have taken on the merchant’s subscription flow, customer follow-ups, cancellation handling, form intake, and reporting into Google Sheets for people who bought the bundles.
That’s the actual takeaway for anyone evaluating this kind of infrastructure. Queues, unique code generation, retry logic, and ledger writes built to survive a one-time spike turn out to be the right shape for steady-state operations too. You don’t design for that up front. You just don’t have to throw it away once the spike is over. It’s the same principle behind how MESA supports enterprise-scale automation for merchants who never expect a single-day spike at all, just steady, high volume every day.
The certificate
The certificate sits on our engineer’s desk. Before the next launch on the calendar (and there’s always a next one), someone on our team will run another stress test against another data table and come back with another set of numbers.
It’s what we do.
If you’re evaluating whether an automation layer can hold up under real load, the numbers above are the pitch.
