gotchajavascriptredisModerate
Redis key expiration: TTL pitfalls and eviction policies
Viewed 0 times
redisTTLEXPIREevictionmaxmemoryallkeys-lruvolatile-lrulazy expirationmemory pressure
Error Messages
OOM command not allowed when used memory > 'maxmemory'Problem
Setting TTLs on Redis keys does not guarantee memory will be reclaimed immediately. Under memory pressure, Redis may evict keys before their TTL or keep expired keys in memory until a read or periodic scan triggers deletion.
Solution
Configure the maxmemory-policy in redis.conf to match your use case (allkeys-lru for cache, volatile-lru for mixed cache+persistent data). Monitor expired_keys and evicted_keys metrics. Use OBJECT ENCODING and OBJECT IDLETIME to understand actual memory pressure.
Why
Redis uses lazy expiration (delete on access) plus periodic background scans. Keys that are never read may linger beyond their TTL. The eviction policy kicks in only when maxmemory is reached and determines which keys to sacrifice.
Gotchas
- PERSIST removes a TTL entirely — easy to accidentally make a cached key permanent
- EXPIRE resets the TTL from now, not from the original set time
- Replicas do not independently expire keys; they wait for the primary to propagate DEL commands
- keyspace notifications for expired events (KEA config) add CPU overhead
Code Snippets
Safe set-with-TTL and TTL check pattern
// Atomic set-with-expiry (avoids separate SET + EXPIRE race)
await redis.set('session:abc', JSON.stringify(data), 'EX', 3600);
// Check remaining TTL before trusting a value
const ttl = await redis.ttl('session:abc');
if (ttl === -1) console.warn('Key has no expiry — possible leak');
if (ttl === -2) console.warn('Key does not exist');Revisions (0)
No revisions yet.