Practical tips for scaling your app during BFCM, flash sales

Hey y'all. BFCM is here, and hopefully everyone already dotted their i's and crossed their t's to allow the internet to throw the kitchen sink at your Shopify app.

Figured I'd share some practical tips of how to best prepare your apps to meet the challenges of volume spikes that BFCM or a large merchant's flash sale can bring. Probably not in time for this year's traffic onslaught, but hopefully these tips come in handy in the future.

I'll briefly summarize it here, and if it peeks your interest, there's more meat on the bone in this blog post. Been thinking about diving deeper into each of these, let me know if you'd find that helpful.

Anyway, here goes.

Webhooked to oblivion
BFCM traffic can generate magnitudes more webhooks than what you're used to. If your app needs to do any expensive work to process them, things can quickly go south. My recommendation is to process them in a background job where possible. We built one into Gadget's Shopify Connection.

Protect your database
The next bottleneck can be your database. More webhooks leads to more queries, and your DB can get overwhelmed, and lead to application errors and timeouts. I have a few general recommendations

• Scale up your instance size if you can afford it, computers are likely cheaper than your time to deal with whatever comes from not doing this.
• Find and optimize the most common and slowest queries. We use pganalyze at Gadget for this.
• And indexes and remove joins.
• Consider caching results for any queries where the results rarely change

Horizontally scale the app tier
Turn up the knob of your app tier. Depending on your architecture, it's not always easy or possible. But if you can, do it. Serverless deployment tools like Gadget or AWS Lambda shifts the burden of turning the knob up and down onto the platform, eliminating the risk of overpaying for scale you're not using.

Build confidence with data
Finding which part of your app is the weakest link during "spiky" traffic is hard if your app rarely sees that kind of load.

• Use proven tools that scale to make the scaling burden someonelse's problem, like Gadget or other serverless platforms.
• Use synthetic load testing tools to generate load on your production app

During both normal conditions and load tests, it is key to get deep insight into how the various systems that make up your app are performing, and there's a multitude of observability tools for this out there. For logging, tune what logs you want to emit, and I'd recommend adding structured logging.

I would also recommend production error tracking. At Gadget we use Sentry, and apps built in Gadget can connect to Sentry easily using the Sentry Connection.

As mentioned earlier, these tips just scratch the surface of what we should think about when building software that scales, and I cover them in more detail here. If a deeper dive into any of these would be useful to you, please let me know!

Thanks for reading, and hope you spend your BFCM contemplating deals and not errors!