keyvalue-store — Redis/Valkey, production-grade.

Architecture

Classes/
├── Cache/Backend/
│   └── KeyValueBackend.php          (extends TYPO3 Core RedisBackend)
├── Session/Backend/
│   └── KeyValueSessionBackend.php   (implements SessionBackendInterface)
├── Locking/
│   └── KeyValueLockingStrategy.php  (implements LockingStrategyInterface)
└── Connection/
    ├── KeyValueConnectionFactory.php
    ├── SentinelResolver.php
    ├── TlsContextBuilder.php
    └── ValueObject/

All three TYPO3-facing components route their phpredis instantiation through KeyValueConnectionFactory — Sentinel, TLS, mTLS, and the phpredis 6.x backoff are configured in exactly one place.

Requirements

• PHP 8.5+
• TYPO3 ^14.0 (Composer mode)
• ext-redis >= 6.3 (phpredis with v6 constructor-config API)
• Redis 4.0+ or Valkey (UNLINK required)

Configuration

The easiest path is via moselwal/typo3-config — autoconfigureCaching() wires all three components consistently. Manual configuration in config/config.php:

Cache backend

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['pages'] = [
    'backend' => \Moselwal\KeyValueStore\Cache\Backend\KeyValueBackend::class,
    'options' => [
        'hostname'             => 'valkey.internal',
        'port'                 => 6379,
        'database'             => 3,
        'password'             => 'secret',
        'persistentConnection' => true,
        'defaultLifetime'      => 2592000,
        'compression'          => true,
        // TLS/mTLS (optional)
        'tls'                  => true,
        'ca_file'              => '/run/tls/ca.crt',
        'cert_file'            => '/run/tls/httpd.crt',
        'key_file'             => '/run/tls/httpd.key',
        // Sentinel (optional)
        'sentinel'             => true,
        'sentinel_host'        => 'sentinel.internal',
        'sentinel_port'        => 26379,
        'sentinel_service'     => 'mymaster',
    ],
];

Session backend

$GLOBALS['TYPO3_CONF_VARS']['SYS']['session']['BE'] = [
    'backend' => \Moselwal\KeyValueStore\Session\Backend\KeyValueSessionBackend::class,
    'options' => [
        'hostname'             => 'valkey.internal',
        'database'             => 1,
        'password'             => 'secret',
        'persistentConnection' => true,
        'persistentId'         => 'typo3-session-be',
        'prefix'               => 'typo3:sess:be:',
        'sessionLifetime'      => 3600,
    ],
];

Locking strategy

$GLOBALS['TYPO3_CONF_VARS']['SYS']['locking']['strategies'][
    \Moselwal\KeyValueStore\Locking\KeyValueLockingStrategy::class
] = [
    'hostname'             => 'valkey.internal',
    'database'             => 0,
    'password'             => 'secret',
    'persistentConnection' => true,
    'ttl'                  => 10,
];

Dependencies

How v4.x differs from TYPO3 Core's Redis backend

KeyValueBackend extends TYPO3's own RedisBackend and overrides four operations that produce server-side anti-patterns. All other operations (get, has, remove, findIdentifiersByTag) are inherited unchanged — Core already pipelines tag tracking there correctly.

Lazy connect (lazy=true default) — the TCP/TLS handshake is deferred to the first command. Bootstrapping 11 cache backends drops from ~25 ms to ~0.07 ms on a real mTLS Valkey setup (381×). OPT_SCAN = SCAN_RETRY is set on every connection so phpredis 6.x retries empty SCAN pages internally instead of returning false.

Benchmarks (container-side against Valkey/mTLS, phpredis 6.3.0)

Measured container-side against Valkey with mTLS. Numbers compare TYPO3 Core / v4.0.x with v4.3.0.

flush() and collectGarbage() are intentionally slower wallclock-wise for the caller. The trade-off: KEYS blocks every other client in the Valkey instance while it runs. With SCAN, the server can interleave other clients between batches — for a multi-site or multi-pod setup that is the more important property. Neither is a hot path (flush() is BE/CLI-triggered; collectGarbage() runs in the scheduler tick).

Serializer

KeyValueBackend defaults to PHP-native serialization. The serializer option lets you change this per cache backend:

⚠️ Switching the serializer requires a full cache flush of all affected cache databases. Existing payloads remain in the previous format and will fail to deserialize. Recommended deploy sequence:

# 1. Flush each affected Valkey DB
valkey-cli -n 3 FLUSHDB    # pages
valkey-cli -n 4 FLUSHDB    # hash
# ... repeat for each cache DB

# 2. Restart workers so connections re-initialise with the new option

# 3. Deploy the new typo3-config with the serializer change

Why auto is the wrong default: an image update shipping ext-igbinary would silently switch the on-disk format for any cache using auto — the next read of an old PHP-serialised payload would throw. Pinning the value explicitly ('php' or 'igbinary') makes the contract observable.

When igbinary is worth it: only for caches storing deeply nested arrays/objects (e.g. Extbase ClassSchema, Fluid template reflection). For string-content caches (rendered pages, large text blobs) or flat key/value caches (hash, imagesizes), the igbinary encoder overhead dominates the marginal payload-size gain — keep the default.

The session backend (KeyValueSessionBackend) uses JSON internally for debuggability via valkey-cli — this option has no effect there.

Where I use this …

This package carries the cache and session layer in TYPO3 Kubernetes — without a central cache store no multi-pod setup runs cleanly. In the managed variant it runs as part of my AI-Ready CMS as a Service.