【Mockingbird】A pre-BFCM load-testing checklist for your order integrations
Three blind spots internal testing tends to miss, and the checks you can still run now
What this article covers
- What tends to go wrong on sale day in the systems downstream of Shopify
- Why integrations that passed thorough internal testing still break in production
- What you can still verify now, right before BFCM
- How to reproduce sale-level order volume before the real thing with Mockingbird
Black Friday and Cyber Monday ("BFCM"; November 27–30 in 2026) are the peak of the holiday shopping season. Is your order-processing setup ready? On sale day, problems rarely start in Shopify itself. They start in the systems that receive the orders: your OMS, WMS, 3PL, ERP and other integrations. This article looks at three blind spots that internal testing tends to miss, and at how to run a check even now, right before BFCM.
On sale day, the bottleneck is downstream of Shopify
BFCM sales have become a fixture in Japan, too, and stores now see many times their usual order volume concentrated into a few hours.
Shopify itself runs on infrastructure built for traffic at scale. The OMS, WMS, 3PL, ERP, inventory sync and other apps that receive and process those orders, however, differ from store to store in both architecture and capacity. Delayed order imports, inventory allocation mismatches and backed-up fulfillment instructions often surface only once a large volume of real orders starts flowing.
Tested thoroughly in-house, broken in production
You test a new feature or integration carefully, sign it off, release it, and it fails in production anyway. Anyone who builds or runs an e-commerce operation has probably been there. Most of the time, the cause is one of these three:
- Data patterns: combinations that internal testing never quite covers, such as cash on delivery, free shipping, requested delivery dates and time slots, unpaid orders and partial fulfillments
- Order volume: processing time once thousands or tens of thousands of orders pile up, and the limits of reports and aggregations
- Order velocity: notification backlogs when orders arrive in a burst, and the API rate limits of the systems you integrate with
Velocity is the one most often overlooked. The same tens of thousands of orders put a very different load on the systems downstream of Shopify depending on whether they trickle in over half a day or land all at once when the sale opens. A test that feeds orders in slowly can pass cleanly, and the same integration can still fall behind or drop orders when they arrive in a sudden burst.
That is why verifying quality takes a load test in advance: orders shaped like real ones, at a volume and pace close to production. Ideally you run it early, leaving time to fix and retest. Even now, right before BFCM, a test is still well worth running.
Even if you can't fix it now, you can find where it breaks
In the days before BFCM, most teams have frozen releases, and reworking an integration now may not be realistic. But if you know at what volume and pace delays start to appear, you can decide in advance how to operate on the day.
- Identify the volume and pace at which delays begin, and use them as thresholds for monitoring on the day
- Decide the manual fallback when imports lag (re-import, CSV export and so on), including the steps and who owns them
- Confirm the escalation contacts at each integration vendor for the day
- Prepare customer notices for delayed shipments for the warehouse and customer support teams
Pre-BFCM checklist
- Do order imports into your OMS, WMS and 3PL keep up at sale-level volume?
- Do your ERP, accounting and CRM integrations process a large volume of orders without dropping any?
- Can the apps and automations triggered by orders (such as Shopify Flow) handle a burst of notifications?
- Can your warehouse and customer support staff work through procedures sized for the day's order volume?
A tool for load testing: Mockingbird
We build and offer Mockingbird, a Shopify app made for exactly this kind of test. It generates realistic test orders for the Japanese market from the Shopify admin, up to 50,000 per run (Complete plan). Because each order is created individually, just like a real purchase, you can confirm before the sale whether your OMS, WMS, 3PL, ERP and other integrations can handle sale-day volume and velocity.
Feature 1: Orders arrive exactly as real ones do, all the way to your integrations
In the default "real-time creation" mode, orders are created one by one, in parallel, just like real purchases. An order-creation webhook fires for each one, so the OMS, WMS, 3PL and apps that receive orders from Shopify are loaded exactly as they would be on sale day.
Feature 2: Sale-level volume and pace
A single run generates up to 50,000 orders, created back to back as fast as the store will accept them. In our measurements, that was roughly 1,000 orders per minute on a Shopify Plus store and roughly 300 per minute on a standard plan. You can reproduce the burst of orders that hits right after a sale opens, before it happens for real. On standard plans, the "bulk creation" mode, which uses Shopify's bulk operations, creates orders even faster. Daily scheduled runs (Complete plan) are also supported, so you can repeat the same test under the same conditions with every release.
*Creation speed varies with the store's plan, the contents of the orders and conditions on Shopify's side.
Feature 3: Realistic Japanese order data to test your whole workflow
What Mockingbird generates are real Shopify orders flagged as test orders. They include Japanese names with fictional addresses and phone numbers, tax-inclusive and tax-exclusive pricing, shipping fees and free-shipping conditions, cash on delivery, and requested delivery dates and time slots. Payment and fulfillment statuses can be mixed as well, so you can check your whole Japanese workflow, from import to shipping, tax calculation and printed documents. You can also limit generation to specific products and test bundle (set) products.
*The names, addresses and phone numbers shown on screen are all fictional, generated at random by Mockingbird. The addresses do not exist, so nothing will be delivered even if an order is shipped by mistake.
Generated orders are tagged "mockingbird" and "テスト注文" (Japanese for "test order"), which makes filtering and cleaning up after a test easy.
Pricing
| Plan | Monthly | Max orders per run | Scheduled runs |
|---|---|---|---|
| Free | $0 | 10 | ― |
| Lite | $29.99 | 1,000 | ― |
| Complete | $99.99 | 50,000 | Daily |
Mockingbird is available in Japanese and English. Install it from the Shopify App Store and give it a try.
View Mockingbird on the Shopify App Store
We can help you check your integrations
Whether you want to check your integrations before the sale or improve them based on load-test results, we're happy to talk. Drawing on our experience building ERP and WMS integrations, we'll help you work through it. Feel free to get in touch.