A Magento store survives a flash sale or product drop when three subsystems hold under load: full page cache serves anonymous traffic without touching PHP, the checkout defers expensive calculations, and inventory reservations prevent oversells without locking the database. Get those three right and a store that normally handles 200 concurrent visitors can absorb a spike to 5,000 without going down.
The failure pattern is always the same. Traffic arrives faster than the store expected, the database connection pool exhausts, the Varnish cache miss rate spikes because products are being updated mid-sale, and checkout starts timing out at the worst possible moment. None of that is inevitable. Most of it comes from default settings that are tuned for steady traffic, not for a coordinated rush. This playbook walks the four layers that decide whether your next drop converts or crashes, with the exact settings that matter.
Where flash sale traffic actually breaks Magento
A product drop is not just more traffic. It is a specific, hostile traffic shape: thousands of people hitting the same few product pages in the same few minutes, most of them logged in or adding to cart, all competing for the same limited inventory. That combination attacks the parts of Magento that are hardest to cache.
Anonymous browsing scales easily because full page cache serves it. The problems start where caching cannot help: the cart, the checkout, and the inventory system. Every add-to-cart is a personalized, uncacheable request. Every order placement writes to the database and recalculates totals. And every purchase changes salable quantity, which can invalidate the very product-page cache that was protecting you. Scaling a drop means protecting those uncacheable paths, not just serving fast pages.
Layer 1: cache so hard that anonymous traffic never touches PHP
The first job is making sure the browsing rush never reaches your application servers. On a Magento development build that means Varnish as the full page cache in front of the store, with production mode enabled and all caches active. Adobe’s own configuration best practices are explicit that you should “use Varnish, as it is an efficient production page cache solution” and activate every cache type.
The trap during a drop is cache invalidation. If a purchase updates a product and that update flushes the product page from cache, thousands of waiting shoppers all hit an uncached page at once and hammer PHP. Two defenses matter. First, set indexers to Update on Schedule so reindexing happens in controlled background batches rather than on every save, with the one exception Adobe names: the Customer Grid index must stay on Update on Save. Second, keep as much of the page cacheable as possible and push per-user data to private content blocks so the shell of the page survives.
A Hyvä frontend helps here beyond raw speed. Because Hyvä favors small inline scripts and private content over heavy hole-punching, the cached page is lighter and there is less uncacheable machinery to render under load. A store that scores well on Core Web Vitals on a calm Tuesday has more headroom on a chaotic launch day.
Layer 2: defer the expensive work in checkout
Checkout cannot be cached, so the goal is to make each checkout request do less. Adobe Commerce ships several switches for exactly this, and they are all disabled by default because they trade convenience for throughput. During a drop you want the throughput.
The most useful settings, per Adobe’s high-throughput order processing guidance:
| Setting | What it does | How to enable | Default |
|---|---|---|---|
| Deferred Total Calculation | Only the subtotal calculates as items are added; full totals wait until checkout begins | bin/magento setup:config:set --deferred-total-calculating 1 |
Disabled |
| AsyncOrder | Marks orders as “received” and processes them through a queue instead of synchronously | bin/magento setup:config:set --checkout-async 1 |
Disabled |
| Inventory Check On Cart Load | Runs a stock check every time the cart loads; can be turned off because an inventory check always runs at order placement anyway | Stores > Configuration > Catalog > Inventory > Stock Options | Enabled |
Deferred Total Calculation matters because shoppers pile items into carts during a drop and each recalculation is work you do not need until they actually check out. AsyncOrder is the heavier lever: it decouples the customer-facing “order received” moment from the actual order processing, so a burst of orders queues up and drains at a sustainable rate instead of overwhelming the database at once. It supports OnePage and standard checkout, B2B negotiable quotes, and specific payment methods including PayPal, Braintree, and offline methods, so confirm your payment method is covered before you rely on it.
For readers going deeper on the checkout path itself, our Magento checkout optimization playbook covers the conversion side of the same flow.
Layer 3: inventory that does not oversell or deadlock
Overselling during a drop is a support nightmare and a refund liability. Underselling by locking rows is a revenue leak. Magento’s Multi-Source Inventory solves this with reservations, an append-only ledger that records intent to reduce stock without immediately writing to the source item, which avoids the row-level lock contention that would otherwise serialize your checkout under load.
Two things have to be true for reservations to work during a spike. First, the message queue consumer that keeps salable quantity current has to be running. Adobe’s message queue consumers documentation names it directly: inventory.reservations.updateSalabilityStatus “asynchronously updates the salable quantity of each product assigned to a stock” and “should always be up and running if you are using Inventory Management.” If that consumer stalls, salable quantity drifts and your storefront shows stock that is already gone.
Second, consider enabling Use Deferred Stock Update during the sale, which lets Commerce batch stock updates related to orders instead of writing each one immediately. It requires backorders to be enabled and it trades real-time stock accuracy for throughput, so it is a during-sale setting you turn on deliberately, not a permanent default. If reservations are new to your team, our explainer on how inventory reservations prevent oversells covers how salable quantity is really calculated and how it drifts.
Layer 4: the infrastructure underneath
Software settings only go as far as the hardware and topology allow. For high-traffic events the levers are read scaling and process health.
On Adobe Commerce Cloud you can split read traffic off the primary database by setting MYSQL_USE_SLAVE_CONNECTION: true and REDIS_USE_SLAVE_CONNECTION: true in .magento.env.yaml, so browsing reads do not compete with checkout writes on the same node. On self-hosted infrastructure the equivalent is a read replica and a Redis instance sized for the session and cache load you expect at peak, not at average.
Then there is cron and the consumers. Indexers, cache flushes, and the inventory queue all depend on cron running cleanly. A backed-up queue during a drop is invisible until salable quantity is wrong and customers are seeing stale stock. Baseline your cron and indexer health before the event, not during it. Server response time caps everything else, so if your time to first byte is already marginal on a normal day, fix that first, because load makes it worse.
What to watch live during the event
Readiness work sets the ceiling, but a drop still needs eyes on it in real time, because the failure signals appear minutes before customers feel them. Watch four numbers on one screen. Cache hit rate tells you whether Varnish is absorbing the browsing rush or leaking requests to PHP. Database connection count tells you how close you are to exhausting the pool that takes down checkout. Message queue depth, especially the inventory salability consumer, tells you whether salable quantity is keeping pace with orders or falling behind into stale-stock territory. And checkout error rate is the customer-facing number that everything else predicts.
The value of watching these together is that they let you act before the crash rather than after. A climbing queue depth is your cue to check that consumers are alive. A falling cache hit rate is your cue to look for a cache flush someone triggered mid-sale. Set thresholds and alerts on these before the event so the on-call person is reacting to a chart, not to a flood of support tickets.
A pre-drop readiness checklist
Run this in the two weeks before a major sale, not the night before.
- Confirm Varnish is serving and measure your cache hit rate under a load test, not just at rest.
- Enable Deferred Total Calculation, and enable AsyncOrder if your payment method supports it.
- Verify the
inventory.reservations.updateSalabilityStatusconsumer is running and keeping up. - Decide whether Use Deferred Stock Update is worth turning on for the event, and enable backorders if so.
- Set indexers to Update on Schedule, leaving Customer Grid on Update on Save.
- Split database and Redis reads to replicas, or provision a read replica if you do not have one.
- Load test at your projected peak, then at double it, and watch database connections, queue depth, and checkout error rate.
- Pre-warn your payment, fraud, and shipping providers, because a spike hits their systems too. This is where a deep integration partner ecosystem earns its keep.
Peak season readiness is not Magento-specific work only. We run the same discipline for merchants on Shopify, BigCommerce, and Shopware, but Magento gives you the most levers to pull, which is both its strength and the reason defaults are not enough. As the first US-based Hyvä Gold partner, Bemeir has taken stores through drops that multiplied normal traffic many times over, and you can read how the team works on the about Bemeir page.
FAQ
How much traffic can a well-tuned Magento store handle during a flash sale?
There is no single number, because it depends on your hosting, catalog, and how personalized your pages are. The useful framing is headroom: a store that serves anonymous traffic almost entirely from Varnish and defers expensive checkout work can absorb an order-of-magnitude spike, moving from a couple of hundred concurrent visitors to several thousand, before checkout throughput becomes the limit. Load testing at your real projected peak is the only way to know your ceiling.
What is the single most important setting for a product drop?
Full page cache actually serving your browsing traffic. If anonymous product-page requests reach PHP and the database instead of Varnish, nothing else you tune will save you, because the browsing rush alone will exhaust your resources before anyone checks out. Confirm your cache hit rate under load first, then tune checkout and inventory.
Will AsyncOrder cause overselling if orders are processed later?
No, because an inventory check always runs at the order placement step regardless of other settings, and reservations track committed stock as orders are received. AsyncOrder changes when the heavy order processing happens, not whether stock is checked. You still need the salable quantity consumer running so the storefront reflects reality as the queue drains.
Should I leave these performance settings on all year?
Some yes, some no. Varnish, scheduled indexing, and read replicas are good permanent practice. Deferred Total Calculation is usually safe to leave on. Use Deferred Stock Update trades real-time accuracy for throughput and is better treated as an event setting you enable for the sale and reassess afterward.
Does Hyvä help with flash sale performance or just everyday speed?
Both. The same properties that give Hyvä strong Core Web Vitals, a lighter cached page and less uncacheable client-side machinery, mean there is less work to do per request under load. Everyday speed and peak-load headroom come from the same place, so a fast baseline is your best flash-sale insurance.
