Currently the redis store stores all values in a single hash using HGET / HSET. Optionally if the cache definition has a TTL then that is honored using a moodle task which was added in MDL-72328 in 4.0.

The down of using hashes is that they don't support cache eviction policies, either the whole hash is evicted or not it doesn't do evictions at the level of items inside the hash.

https://redis.io/docs/reference/eviction/

The downside of using the TTL value card coded into the cache.php definition is that you can't see it, tune it and in many cases it will just be evicting data that it still current for no reason, and it still doesn't help you if you are running out of memory and want to free up space.

So proposing to have either more options in the redis store, or possibly just making a second redis store implementation which uses normal keys and SET+EX which then allow key eviction policies. The expiry time will be effectively 'infinite' by default which just marks them as volatile and allows them to be evicted when needed. If the cache definition does specify a TTL then we could pass it through too

The downside is that purges are not as easy but still viable.

I'd lean towards a whole new cache store or there will be a ton of messy code forks in the code. Some of shared logic like compression could be pulled into a trait.