"maxmemory-policy noeviction" seemed safe. No data loss, right?

What happened:

  • Redis hit its maxmemory limit
  • noeviction policy: Redis stayed up but rejected every write with "OOM command not allowed when used memory > 'maxmemory'" — no crash, just refusals
  • Application couldn't write new cache entries
  • But it also couldn't write session data
  • Users got logged out mid-transaction
  • Payment failures spiked 400%

The real problem:

We stored both disposable cache AND critical session data in the same Redis instance with the same eviction policy. Either policy choice sacrifices one workload: eviction throws away live sessions, noeviction blocks the cache. (We'd already learned the hard way that sessions in Redis need their own operational rules.)

The fix:

  • Separate Redis instances for cache vs. sessions
  • Cache: allkeys-lru (evict oldest when full)
  • Sessions: noeviction + aggressive TTLs + monitoring
  • Alerts when memory hits 80%

Lesson: Your eviction policy should match your data's importance. Disposable cache and critical sessions need different strategies.

← Back to Lessons Learned
Tags: #Redis #Caching #Memory #Debugging