The tyranny of the traditional stack
The standard architecture for a scalable Adobe Commerce installation has been consistent for a decade. A cluster of PHP application servers sits behind a load balancer, which in turn sits behind a full-page cache layer, almost always Varnish. This stack, recommended in the official Adobe Commerce documentation, works. When correctly configured, Varnish is exceptionally fast, serving pages from memory without ever touching the expensive Adobe Commerce application bootstrap. For a UK-centric business serving UK-based customers from a UK data centre, it's a proven model.
The problem is that 'correctly configured' is doing a lot of work in that sentence. Varnish Configuration Language (VCL) is a specialised skill, and the logic required to handle cache variations for different customer groups, currencies, and session states in B2B commerce can become frighteningly complex. Misconfigurations are common, leading to difficult-to-diagnose caching issues, stale content, or data leakage between users. This complexity creates a fragile dependency. The Varnish server itself becomes a critical point of failure, and the VCL files become a form of technical debt that few on the team fully understand or are confident enough to change. For many businesses, it's a black box at the most critical point of their infrastructure.
Moving the cache from the server to the network
The alternative is to treat caching not as a separate server to be managed, but as a service provided by the network. A modern content delivery network, or what is now better termed an application services network like Cloudflare, can do far more than just cache static assets. With features like Tiered Cache and programmable edge logic via Workers, the entire function of Varnish can be migrated from your hosting environment to the network edge, physically closer to your global customers.
Here is how it works in principle. Instead of traffic hitting your Varnish server, it first hits one of Cloudflare's hundreds of global data centres. A Cloudflare Worker, which is essentially a piece of JavaScript running on their network, intercepts the request. This worker contains the logic that decides if the page can be served from cache. If it is cached, it's served directly from that data centre with a sub-50ms time-to-first-byte (TTFB). If it's not cached in that specific location, Tiered Cache allows that data centre to request it from a regional hub, which is more likely to have a copy, before finally making a single request back to your origin server. This massively reduces the load on your core infrastructure.
"This architectural shift treats caching as a solved problem. It lets your team focus on building business features, not managing the intricacies of a caching subsystem."
Replicating Varnish logic at the edge
This is not a simple switch. The VCL logic that handles cache invalidation, grace periods, and ESI (Edge Side Includes) for dynamic blocks like the mini-cart must be replicated in the Cloudflare Worker. Specifically, cache tagging becomes critical. When a product is updated in the Adobe Commerce admin, you need a way to tell the edge network to invalidate every cached page that contains that product. This is typically done by adding a response header containing a list of tags (e.g., 'product-123', 'category-45') to every page served by the origin. The Worker stores these tags alongside the cached response. A subsequent API call to Cloudflare can then purge all content associated with 'product-123' globally in seconds.
While this sounds complex, it's a programmatic and testable approach, unlike editing and deploying monolithic VCL files. The logic lives as code in a version control system, can be deployed incrementally, and is often simpler to reason about than the stateful, procedural nature of VCL. For dynamic content, a Worker can either punch holes for private content or run ESI-like logic, assembling a page from multiple cached fragments at the edge. This delivers the benefits of a highly-dynamic site without the performance penalty of making every request un-cacheable, a common challenge we see in B2B commerce scenarios with customer-specific catalogues and pricing.
The business case: Simpler, faster, more resilient
Eliminating the dedicated cache layer has three primary business benefits. First is operational simplicity and cost reduction. You have one less piece of critical infrastructure to provision, patch, pay for, and monitor. You also reduce the reliance on a very niche skillset, VCL, which makes hiring and retention easier and reduces key-person risk. This is especially valuable in complex environments like the builders merchants sector, where stability is paramount.
Second is performance and resilience. By caching at the network edge, you serve content significantly faster to a geographically distributed user base. An Australian user hitting our client Huws Gray's website gets a response from a Sydney data centre, not one routed all the way to the UK. Furthermore, the resilience of the platform increases. Cloudflare's network can absorb enormous DDoS attacks, and its scale means the failure of a single server or even a whole data centre is a non-event for end-users. Your origin infrastructure is shielded from almost all traffic, meaning it can run on smaller, less expensive hardware.
Ultimately, this architectural shift treats caching as a solved problem, a utility to be consumed from a specialist provider. It allows your engineering team to focus on building business features within Adobe Commerce, rather than spending their time managing the intricacies of a caching subsystem. For any business considering a major replatform or undertaking significant rescue projects on their existing site, abstracting away the cache layer should be a primary strategic consideration.
