Implementing TYPO3 with Redis Cache: Architecture, Trust Boundaries, and Operational Checks

Why Redis for TYPO3?

TYPO3’s default caching uses the file system, which can become a bottleneck when you run multiple web servers behind a load balancer. Redis, an in‑memory key‑value store, gives you sub‑millisecond read/write times and lets several instances share the same cache namespace. This article shows the minimal architectural requirements, how to keep data trust boundaries clean, and what to monitor so that a Redis outage doesn’t break your site.

Requirements Checklist

• PHP Redis extension (php‑redis) installed and enabled on all web servers.
• Reachable Redis server (single instance or cluster) with a dedicated database number.
• TYPO3 12+ (or 11.5 LTS) with the CacheFramework configured to use Redis.
• Network access: tcp://redis-host:6379 must be reachable from every web node.
• Optional: password, TLS, or ACLs if you need isolation beyond the database number.

Smallest Viable Design

TYPO3 already ships a Redis cache backend. All you need is a LocalConfiguration.php entry that points to the server and sets a unique prefix so your keys don’t clash with other applications on the same Redis host.

return [
    'SYS' => [
        'caching' => [
            'cacheConfigurations' => [
                'pages' => [
                    'backend' => 'TYPO3\Cache\Backend\RedisBackend',
                    'options' => [
                        'host' => 'redis-host',
                        'port' => 6379,
                        'database' => 1,
                        'password' => 'mySecret', // optional
                        'prefix' => 'typo3_pages_',
                        'compression' => true,
                        'compressionLevel' => 5,
                    ],
                ],
            ],
        ],
    ],
];

In this example we configure the pages cache. The same pattern applies to other cache identifiers such as fluid_template or frontend_user. The prefix isolates your keys; if you share a Redis instance with another TYPO3 installation, give each a different prefix.

Trust & Data Boundaries

Who writes the data?

Application code (frontend or backend) writes cache entries. The cache framework serializes PHP values automatically. Redis is treated as a trusted component because it runs in a controlled data center or your own VMs. However, you must avoid storing sensitive user data in the cache unless you encrypt it first.

Session Data Considerations

TYPO3 supports storing session data in Redis, but this requires careful isolation:

• Use a dedicated database number or a strict prefix per tenant.
• Enable TLS or ACLs if the Redis instance is exposed to the internet.
• Encrypt session payloads if they contain PII.

Operational Checks

Health Monitoring

• Latency: Run redis-cli --latency or a custom script that issues PING and measures round‑trip time. Keep it under 1 ms for production.
• Key Count & Eviction: redis-cli INFO keyspace shows keys and expires per database. Verify that the eviction policy (e.g., volatile-lru) matches your workload.
• Namespace Isolation: Use redis-cli keys typo3_pages_* to count only your site’s keys.
• Cache Backend Type: In TYPO3 backend, go to Admin Tools → Cache → Statistics and confirm the backend shows RedisBackend. In debug mode, TYPO3_CONTEXT=Development logs the backend type.

Performance Verification

1. Flush the cache: php bin/typo3 cache:flush.
2. Load a page and wait for the first render.
3. Check Redis key count: redis-cli -n 1 KEYS typo3_pages_* | wc -l.
4. Reload the page and observe that the key count does not increase, indicating reads hit Redis.

Failure Modes & Automatic Recovery

• Redis Down: TYPO3 falls back to the file cache. The first request after a failure will be slower, but subsequent requests use the file cache until Redis is back.
• Connection Loss: The PHP Redis client automatically attempts to reconnect. If reconnection fails for more than 5 seconds, the cache entry is considered a miss.
• Eviction Events: If the eviction policy is too aggressive, you’ll see cache misses. Monitor redis-cli MONITOR or INFO memory to see eviction counts.

When to Redesign

• High eviction rates: If you notice that more than 10 % of cache hits are evicted within a minute, consider increasing the max memory or switching to allkeys-lru.
• Multi‑tenant isolation: When multiple TYPO3 instances share a Redis host, move each to its own database or use separate Redis servers.
• Persistence requirement: If you need crash‑recovery of cache data, enable appendonly yes or save snapshots, but remember this adds latency.
• Encryption requirement: If cache entries contain PII, implement application‑level encryption before caching.

Practical Checklist Before Going Live

Step	Action	Check
1	Install php‑redis on all web nodes.	php -m | grep redis
2	Configure LocalConfiguration.php with correct host/port/database.	TYPO3 backend shows RedisBackend.
3	Run php bin/typo3 cache:flush.	Redis key count > 0.
4	Simulate Redis failure (systemctl stop redis).	Page loads slowly, no Redis key increments.
5	Restart Redis and verify performance returns to baseline.	Redis key count stable, latency < 1 ms.

Conclusion

Using Redis as a TYPO3 cache backend is a supported, low‑overhead upgrade that scales out across multiple web servers. By keeping the configuration minimal, isolating keys with prefixes, and monitoring latency and eviction, you can avoid surprises when Redis hiccups. If your workload grows or you need stronger isolation, revisit the eviction policy, database allocation, or consider a dedicated Redis cluster.