Peak-trading readiness for Adobe Commerce

Every year, the same pattern: an Adobe Commerce store sails through the preceding eleven months, then falls over at 9am on Black Friday. The cause is never a mystery — insufficient capacity, stale cache configuration, or a queue backlog that wasn't stress-tested at realistic traffic levels. The same stores come back the following year. The problem is always fixable. It's never prioritised until it's urgent.

We run a peak-trading readiness process for every managed Adobe Commerce client each autumn. Here's exactly what it involves and what it typically finds.

Step 1: Baseline the current stack

Before running any load tests, we establish what the current infrastructure can handle and where the weak points are. This involves reviewing the Varnish and Redis configuration, the database query profile under normal load, the CDN setup for product images and static assets, and the queue runner configuration for order processing.

Most stores we inherit have Varnish configured conservatively — cache TTLs set low to avoid stale content — and Redis maxmemory policies that evict under pressure. Neither configuration is wrong for normal traffic, but both create problems at peak.

Step 2: Load test against realistic traffic profiles

Peak-trading traffic is not uniform. It comes in waves — triggered by email campaigns, social posts and partner promotions — and the demand profile is heavily weighted towards the catalogue and checkout, not the homepage. We model traffic scenarios based on the client's actual peak from the previous year and scale them up by a conservative margin.

• Catalogue browse: 500–2,000 concurrent users hitting product listing pages
• Product detail pages: high-volume with personalisation and stock-check API calls
• Checkout flow: simulated concurrent checkouts at realistic conversion rates
• Order confirmation + post-order queue: order processing under sustained load

What the load tests typically reveal

Database connection exhaustion under concurrent checkout load is the most common finding. Magento's checkout creates multiple database transactions in sequence, and connection pooling that works fine at normal traffic can saturate at three to four times the load.

The second most common finding: Varnish bypasses on pages with dynamic blocks. It's easy to add a personalisation or stock-level block to a template and forget that it sets a no-cache header. Under load, those pages hit the application server on every request. We identify and fix every Varnish bypass before peak.

Step 3: Tune, test again, repeat

Load testing is only useful if the findings are acted on. After each test run we address the highest-impact issues — connection pool sizing, Varnish configuration, Redis maxmemory and eviction policy, queue runner scaling — and re-run to confirm the fix held. We continue this cycle until the store handles 150% of the expected peak without degradation.