Choosing Cache Backends for Magento 2.4.x: Redis, Varnish, and Database/File Options

The decision you face

Magento 2.4.x lets you pick separate backends for full‑page cache (FPC) and session storage. The choice determines latency, horizontal scaling, operational overhead, and compliance posture. This guide states the constraints, compares the supported options in a compact table, explains the trade‑offs, and shows a concrete configuration plus validation steps you can run on a staging server.

Constraints that shape the choice

• Traffic profile – high‑traffic B2C (>500 req/s) needs sub‑millisecond FPC and session clustering.
• Team size – small teams may lack capacity to operate Varnish + Redis.
• Compliance – PCI DSS requires encryption in transit and at rest for any PII in sessions.
• Infrastructure – existing Redis Cluster or managed Elasticache influences whether you can use tag‑aware invalidation.

Supported backends at a glance

Backend	Role	Latency	Scaling model	Operational cost	Tag‑aware invalidation	PCI‑ready
Redis (single instance or Sentinel)	FPC & sessions	~0.5 ms	Vertical + Sentinel HA; Cluster breaks tag invalidation	Medium (dedicated instance, monitoring)	Yes (native tag keys)	Yes with TLS + at‑rest encryption
Varnish 6.x/7.x	FPC only (edge)	<1 ms (serves HTML without PHP)	Horizontal via multiple Varnish nodes + shared backend	High (VCL tuning, TLS termination upstream)	Via X-Magento-Tags-Pattern header	Depends on upstream TLS termination
Database (MySQL/MariaDB)	FPC & sessions	5‑20 ms (write contention on cache/cache_tag)	Vertical only	Low (no extra service)	No (purge scans tables)	Yes if DB encrypted
File system	FPC & sessions	10‑50 ms (inode pressure, no TTL enforcement)	Single node only	Lowest	No	Only if volume encrypted

Trade‑offs explained

Redis for FPC

Redis gives sub‑millisecond reads and built‑in LRU eviction (maxmemory-policy: allkeys-lru). Magento stores cache tags as Redis sets, so invalidation is a single DEL per tag. Enable compression for large catalogs (compress_data: 1) and use a dedicated instance per environment. Magento 2.4.6+ supports Redis Sentinel for HA; Cluster mode is not compatible with tag‑based invalidation because keys are sharded across slots.

Varnish for FPC

Varnish sits in front of Magento and serves cached HTML without bootstrapping PHP. It requires a generated VCL (bin/magento varnish:vcl:generate) that handles X-Magento-Tags-Pattern for tag‑based purges. TLS must be terminated upstream (nginx, ALB). Health checks should probe /health_check.php with Accept: text/html. Varnish adds two infrastructure components (Varnish + Redis for sessions) but delivers the highest cache‑hit ratios for anonymous traffic.

Database / file backends

Supported but not recommended for production FPC. Database cache adds write contention on cache/cache_tag tables; file cache suffers from inode exhaustion and lacks native TTL enforcement across nodes. They may be acceptable for low‑traffic B2B stores (<50 req/s) with a nightly cache:clean cron and increased max_execution_time.

Session storage

Redis sessions avoid core_session table locking, survive app‑server restarts, and enable session clustering. File sessions work only on a single node. Redis session locking uses a LOCK key with a 30 s TTL; long‑running imports may hit the lock wait timeout – increase redis.session.lock_max_wait or offload heavy work to async queues.

Concrete implementation: Redis FPC + Redis sessions + Varnish edge

Assumes Magento 2.4.6, PHP 8.2, phpredis 5.3+, Varnish 7.x, and a managed Redis instance with TLS.

1. Configure app/etc/env.php

return [
    'cache' => [
        'frontend' => [
            'default' => [
                'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
                'backend_options' => [
                    'server' => 'redis-fpc.example.com',
                    'port' => 6380,
                    'database' => 0,
                    'password' => '{{REDIS_FPC_PASSWORD}}',
                    'compress_data' => 1,
                    'compression_lib' => 'gzip',
                    'maxmemory_policy' => 'allkeys-lru',
                    'tls' => true,
                    'ca_cert_file' => '/etc/ssl/certs/ca-bundle.crt',
                ],
            ],
            'page_cache' => [
                'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
                'backend_options' => [
                    'server' => 'redis-fpc.example.com',
                    'port' => 6380,
                    'database' => 1,
                    'password' => '{{REDIS_FPC_PASSWORD}}',
                    'compress_data' => 1,
                    'compression_lib' => 'gzip',
                    'maxmemory_policy' => 'allkeys-lru',
                    'tls' => true,
                    'ca_cert_file' => '/etc/ssl/certs/ca-bundle.crt',
                ],
            ],
        ],
    ],
    'session' => [
        'save' => 'redis',
        'redis' => [
            'host' => 'redis-session.example.com',
            'port' => 6380,
            'password' => '{{REDIS_SESSION_PASSWORD}}',
            'database' => 2,
            'compression_threshold' => 2048,
            'compression_library' => 'gzip',
            'lock_max_wait' => 10,
            'tls' => true,
            'ca_cert_file' => '/etc/ssl/certs/ca-bundle.crt',
        ],
    ],
    'http' => [
        'cache_hosts' => [
            [
                'host' => 'varnish.example.com',
                'port' => 80,
            ],
        ],
    ],
];

Replace the placeholder passwords with values from your secret manager. Run this change on the app server as the Magento file‑system owner (typically magento user). After editing, clear config cache:

bin/magento cache:clean config
bin/magento cache:flush

2. Generate and deploy Varnish VCL

bin/magento varnish:vcl:generate --export-version=7 \\
    --host varnish.example.com --port 80 \\
    --output /etc/varnish/default.vcl

Reload Varnish (requires root or sudo):

systemctl reload varnish

3. Validate the stack

1. Redis hit ratio – run on the Redis host (or via redis-cli -h redis-fpc.example.com -p 6380 -a $PASS):

   redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'
   # compute hit_ratio = hits / (hits + misses)
   

   Target > 90 % for FPC.
2. Varnish hit ratio – on the Varnish host:

   varnishstat -1 | grep -E 'cache_hit|cache_miss'
   # hit_ratio = cache_hit / (cache_hit + cache_miss)
   

   Target > 95 % for anonymous traffic.
3. Load test – from a separate load‑generator box:

   wrk -t4 -c100 -d60s -H 'Accept: text/html' https://staging.example.com/
   

   Expect p99 < 50 ms for cached pages.
4. Tag invalidation check – after saving a product in Admin:

   redis-cli --scan --pattern 'zc:k:*' | head -5
   # keys should disappear or be evicted within seconds
   

5. Log verification – tail var/log/debug.log for cache_invalidate entries matching catalog/category saves.

Limitations & when to choose a simpler stack

• Redis Cluster breaks Magento’s tag invalidation – avoid for FPC unless you implement a custom invalidation layer.
• Varnish 4/5 VCL syntax differs; Magento‑generated VCL targets 6.x/7.x only.
• Session lock timeout (default 30 s) can stall long imports – tune lock_max_wait or move heavy jobs to RabbitMQ consumers.
• Cache warming after deploy: bin/magento cache:warm only populates built‑in FPC; Varnish needs a separate crawler (e.g., magento2-cache-warmer) to pre‑fill edge cache.
• PCI DSS: ensure Redis TLS (tls: true) and at‑rest encryption on the managed instance; Varnish traffic must be encrypted upstream.

If your team cannot operate Varnish and a dedicated Redis instance, a single Redis for both FPC and sessions (with Sentinel HA) still delivers > 90 % hit ratios for many mid‑size stores. Database or file backends remain a fallback only for low‑traffic, single‑node B2B sites.

Quick checklist before go‑live

• app/etc/env.php contains Redis TLS certs and correct database numbers.
• Varnish VCL compiled without errors (varnishd -C -f /etc/varnish/default.vcl).
• Redis maxmemory-policy set to allkeys-lru and memory headroom > 20 %.
• Load test meets p99 < 50 ms and hit‑ratio targets.
• Monitoring alerts on Redis evicted_keys and Varnish cache_miss spikes.