Users are being logged out at random, or cache hit rates have collapsed, or writes are failing with an out-of-memory error. Redis has reached its memory ceiling and is behaving according to a policy that was probably never chosen deliberately. Which of those three symptoms appears depends entirely on that setting.
01The policy determines the failure mode
With noeviction, Redis refuses writes once full and returns errors while continuing to serve reads. For a cache this is usually wrong - it converts a memory problem into an application error. For a queue or a store of record it may be correct, since silently discarding data is worse.
The allkeys policies evict from the entire keyspace, and the volatile policies only evict keys carrying an expiry. That distinction causes a specific and common outage: with a volatile policy and no keys carrying a TTL, there is nothing eligible to evict, so Redis starts rejecting writes despite the policy suggesting it should make room.
| Policy | Evicts | Suitable for |
|---|---|---|
| noeviction | Nothing - writes fail | Queues, stores of record |
| allkeys-lru | Least recently used, any key | General purpose cache |
| allkeys-lfu | Least frequently used, any key | Caches with stable hot sets |
| volatile-lru | Least recently used, with TTL only | Mixed cache and persistent data |
| volatile-ttl | Shortest remaining TTL first | Time-sensitive caches |
02Do not mix sessions and cache in one instance
Sessions and cache entries have fundamentally different tolerances. An evicted cache entry costs a recomputation; an evicted session logs a user out mid-task. Placing both in one instance under one policy means the cache workload determines whether your users stay authenticated.
Separate instances let each take the correct policy - aggressive eviction for the cache, no eviction with generous memory for sessions. This is the single most valuable change for teams experiencing mysterious logouts, and it is straightforward to implement.
03Set maxmemory below the machine limit
If maxmemory is unset or set to the full capacity of the host, Redis has no eviction trigger and will grow until the operating system terminates it. That is an abrupt total loss of contents rather than a graceful degradation.
Leave headroom - commonly around a quarter of available memory. Redis needs working space for replication buffers, client output buffers and any background save operation, and a fork for persistence can transiently increase memory use considerably on a write-heavy instance.
| Metric | Signals |
|---|---|
| used_memory versus maxmemory | How close to eviction |
| evicted_keys | Active eviction, rising means pressure |
| keyspace_hits and misses | Cache effectiveness |
| expired_keys | Natural TTL expiry, healthy |
| mem_fragmentation_ratio | Above 1.5 suggests fragmentation |
| blocked_clients | Contention or slow commands |
04Every cache key needs an expiry
Keys without a TTL persist until evicted or deleted explicitly. Cached values written once during a migration or a one-off script accumulate permanently and consume memory that active data needs, and they are invisible in normal operation.
Set a TTL at write time as a rule, with no exceptions for cache data. It bounds growth, guarantees eventual consistency with the source of truth, and makes volatile eviction policies function as intended rather than finding nothing to evict.
05Find out what is consuming the memory
Before adding capacity, establish what is stored. Redis can sample the keyspace and report the largest keys, and it is common to find one unexpectedly large structure - an unbounded list acting as a queue nobody consumes, or a set that grows without limit - occupying a disproportionate share.
Scale up only after that check. Doubling memory to accommodate a key that should not exist buys a few weeks and leaves the underlying growth pattern intact, so the same alert returns at a larger and more expensive size.
Topics
Aarav Patel
Principal Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer