The WordPress cache stack that actually survives Black Friday

There is one question every managed WordPress site eventually faces: what blows up under a 50× traffic spike? The short answer is usually the database — not because MySQL is bad, but because every cache layer between the visitor and the database is misconfigured, missing, or doing the wrong job.

The four caches that matter

A production WordPress site needs four cache layers, and the order matters:

1. Edge cache — Cloudflare, BunnyCDN, CloudFront. Catches anonymous traffic at the network edge.
2. Page cache — WP Rocket, W3 Total Cache, LiteSpeed Cache. Serves full HTML from disk or memory for repeat anonymous hits.
3. Object cache — Redis or Memcached, via Object Cache Pro or W3TC. Avoids round-tripping to MySQL for things like get_option(), get_transient(), and WooCommerce session reads.
4. Opcode cache — PHP OPcache, configured with opcache.validate_timestamps=0 in production. Avoids re-compiling PHP files on every request.

If you skip the object cache, MySQL becomes the bottleneck the moment your edge cache misses. If you skip the opcode cache, your CPU floor is 2-3× higher than it needs to be. If you skip the edge cache, you'll pay for every bot that ever indexes your site.

What we actually configure

For a WooCommerce site doing 100k monthly orders we typically deploy:

• Cloudflare in front, with HTML cache tuning per route (catalog pages aggressive, cart/checkout bypass-by-cookie)
• WP Rocket for page cache, with WP_CACHE enabled and the disk cache living on an SSD volume
• Redis with Object Cache Pro for the object cache (the free redis-cache plugin works but Pro is faster under contention)
• OPcache with 256 MB allocated and opcache_reset() triggered on every deploy
• A separate Redis instance for WooCommerce session storage so checkout doesn't fight other reads

Full piece on Medium covers the actual config files, the deploy hook that resets each layer, and the monitoring dashboards we put on top.