Black Friday Post-Mortem: Shopify Performance Lessons from Peak Trading

Black Friday is the stress test nobody can fully simulate. You can load test your integrations and optimise your theme until the scores look perfect, but there's always something that breaks under the weight of real peak traffic.

This year I supported four Shopify Plus stores through Black Friday and Cyber Monday. Three went smoothly. One didn't. Here's what I learned.

The thing that actually broke

It wasn't Shopify. Shopify's infrastructure handled the traffic without any issues — checkout stayed fast, the admin remained responsive, and the APIs held up. That's the advantage of a SaaS platform during peak.

What broke was a third-party app that handled product bundling. Under normal traffic, it responded in 200ms. Under Black Friday traffic, its servers couldn't cope. Response times climbed to 4-5 seconds, then it started returning errors. Because the app injected content into the product page via a JavaScript call, every product page hung waiting for the response.

We disabled the app at 9:15am on Black Friday morning. The bundles disappeared from the site. Revenue from bundles was lost. But the rest of the store recovered immediately.

The lesson isn't "don't use apps." It's "understand which apps are in your critical rendering path and have a plan for when they fail." This is one of the reasons I advocate for building custom where it matters — you control the infrastructure when it counts.

Theme performance under load

Traffic spikes don't just test server capacity — they test every assumption your theme makes about loading speed. Third-party scripts that are fine at normal traffic compete for bandwidth during peak. Fonts from external CDNs get slower. Analytics scripts that normally load in the background suddenly block rendering because the network is saturated.

Before next peak, audit your theme's network requests. Every external call is a risk during high traffic. Consider self-hosting critical fonts and scripts. Defer anything non-essential.

One store I worked with reduced their third-party script count from 24 to 9 in the weeks before Black Friday. Their Time to Interactive improved by 1.8 seconds on mobile. That's not a marginal gain — that's meaningful revenue.

Integration queues and rate limits

Order volume during BFCM is typically 5x to 15x a normal day. If your ERP integration processes orders synchronously via the API, you'll hit Shopify's rate limits well before lunchtime.

Webhook delivery also changes during peak. Shopify makes a best effort, but delivery times can stretch. If your warehouse integration relies on real-time webhook delivery to start picking orders, you might see delays.

The fix is architectural. Queue your webhook payloads and process them asynchronously. Use the API for reconciliation, not as the primary sync mechanism. Build your integration to handle bursts by buffering rather than processing inline. I cover these patterns in more detail in how to choose an ERP integration strategy for Shopify.

One brand I work with processes around 800 orders on a normal day. On Black Friday, they did 6,200. Their integration queue depth hit 3,000 at peak. Because the queue was designed to handle backpressure, it drained cleanly over the following two hours. No lost orders, no duplicates.

Inventory sync timing

During peak, the gap between selling a unit and your stock sync reflecting that sale becomes critical. If your inventory updates from the warehouse every 15 minutes — perfectly fine on a normal day — you can oversell significantly during a high-velocity period.

For Black Friday, either increase your sync frequency or implement a buffer. Reserve stock for your online channel and accept that real-time accuracy isn't possible across all systems during peak.

Overselling three units of a popular product is manageable. Overselling three hundred because your stock sync fell behind is a customer service crisis.

What to do differently next year

Audit every third-party app for performance under load. If an app runs its own infrastructure, ask them about their BFCM scaling plan. If they can't answer, have a plan to disable the app.

Load test your integrations, not just your storefront. Simulate a day's worth of orders in an hour and see what happens to your queue depth, processing time, and error rate.

Pre-warm your caches. Crawl your site before traffic hits to ensure product pages and collection pages are cached. A cold cache during a traffic spike is noticeably slower.

Have a war room plan. Know who's watching what, who can disable an app, who can adjust inventory buffers, and who's monitoring the integration layer. The stores that handle peak well are the ones where someone is watching the dashboards, not the ones hoping nothing goes wrong.

Peak trading is an operational challenge, not just a technical one. Prepare for it like one. And if anyone suggests a headless rebuild will solve your performance problems, make sure you've exhausted the simpler options first.