Magento 2 cache architecture: Varnish, Redis & full-page cache

Performance in Magento 2 is mostly a caching problem solved with the right topology. A production-shaped stack caches at multiple layers, each with a distinct job.

The layers, top to bottom

1. Varnish (full-page cache, edge). Sits in front of the application and serves whole HTML pages for anonymous traffic without touching PHP. This is the single biggest win for storefront speed.
2. Application full-page cache. When Varnish isn't in play (or for cache misses), Magento's own FPC stores rendered pages (often in Redis).
3. Redis (sessions + low-level cache). Session storage and the cache and full_page cache backends live in Redis — fast, shared, and survives restarts.
4. Block/UI cache + EAV/FPC indexes. Fine-grained internal caches keep repetitive work cheap.

Why Varnish leads

For a catalog with mostly anonymous browsing, Varnish can answer the vast majority of requests straight from memory at the edge, with a sub-millisecond response. PHP never starts. The result is dramatically lower TTFB and far higher throughput per node.

Configuring the backends

Cache and session backends are declared in app/etc/env.php. Govard wires Redis and Varnish into the environment automatically — Redis 7.4 for sessions/cache and Varnish 8.0 in front of Nginx — so the local stack mirrors the production-shaped topology you'd actually run.

Gotcha: Varnish serves cached pages based on cache headers and cookies. Misconfigured cacheable blocks or leaky cookies (a session cookie on every page) silently bypass the edge cache.

What's next in this series

Search is the other read path users feel directly. Next: catalog search on OpenSearch (or Elasticsearch) and how the indexer keeps it fresh.

Next in this series: Search with OpenSearch / Elasticsearch — /blog/magento2-search-opensearch