Users logged out at random. Not all, not always. Only sometimes, only in the afternoon. Afternoon is when traffic peaks. Traffic peaks fill the cache. The cache lived in the same Redis as the sessions, the instance hit maxmemory, and the eviction policy was allkeys-lru. Redis did exactly what we asked: threw away the least recently used keys, and some of them were sessions of people who went for lunch.
Eviction policy is not an infrastructure knob. It is application behavior. noeviction means writes start failing with OOM when memory is full, so your code better be ready for a failing SET. The LRU and LFU policies mean any key can vanish at any moment, so everything in that instance must be a cache by contract. Habit does not count. volatile-* sounds safe until nobody set TTLs, Redis has nothing it is allowed to evict, and you are back to failing writes.
So, one instance, one contract. Cache lives where eviction is allowed and expected. Sessions and queues live behind noeviction with monitoring, because a silently evicted job is the worst bug you will never find.
Three numbers to watch in INFO. used_memory against maxmemory, to see the ceiling coming. evicted_keys, which must stay zero on the data instance. And hit rate from keyspace_hits and keyspace_misses, because a cache that misses half the time is a delay with extra steps.
We split the instances in one evening. The logouts stopped. The config diff was four lines. The allkeys-lru line was mine, from the time the instance held only cache.