Redis tends to enter a project quietly. Someone adds it to cache a slow database query, configures it with defaults, and moves on. Eighteen months later, that same instance is also holding user sessions, rate-limiting counters, feature flag state, and a queue or two, none of which were ever written anywhere else first. The instance didn't change. What it's being trusted to do did, and the configuration never caught up.
Cache mode: losing the data is fine, by design
When Redis is genuinely a cache, every key in it is a copy of something that exists somewhere else, or the cost of recomputing it. If Redis restarts and the cache is empty, the application is slower for a bit while it repopulates, but nothing is lost. For this case, the right configuration actively embraces that:
maxmemory 2gb
maxmemory-policy allkeys-lru
save ""
maxmemory-policy allkeys-lru means once Redis hits its memory limit, it evicts the least-recently-used keys to make room for new ones, exactly the right behavior for a cache. save "" disables RDB snapshotting entirely, there's nothing here worth the disk I/O of persisting, since it's all reconstructable.
Database mode: losing the data is a real incident
The moment Redis holds something with no other source of truth, a session that, if lost, logs out every user, a queue of jobs that haven't been processed yet, a counter that resets unexpectedly, the calculus flips completely. Now allkeys-lru is actively dangerous: Redis can decide to evict a session token to make room for a cache entry, and that's not a performance hiccup, it's data loss. The configuration needs to match:
maxmemory-policy noeviction
appendonly yes
appendfsync everysec
noeviction means Redis returns an error on writes once memory is full rather than silently deleting something, which forces you to notice and fix a capacity problem instead of quietly losing data. appendonly yes enables the append-only file for persistence, with everysec balancing durability against write performance, at most one second of writes lost on a crash, rather than everything since the last RDB snapshot.
The actual danger is mixing both, unintentionally
The risky setup isn't "cache" or "database", it's both, in the same instance, under a configuration chosen for one of them. allkeys-lru with both cache entries and session tokens in the same keyspace means Redis can't tell the difference between a cache entry that's fine to lose and a session that isn't, it evicts whatever's least recently used, which might be either. I've seen this cause an intermittent "users randomly get logged out under load" bug that took a while to trace back to cache pressure evicting session keys, because nothing about the symptom pointed at Redis's eviction policy.
Separating them doesn't have to mean separate servers
Redis supports multiple logical databases on one instance (SELECT 0 through SELECT 15 by default), but these share the same maxmemory and eviction policy, so they don't actually solve this. What does is running two Redis instances, even on the same host, each with configuration matched to its job:
redis-server /etc/redis/cache.conf --port 6379
redis-server /etc/redis/store.conf --port 6380
The cache instance gets allkeys-lru and no persistence. The store instance gets noeviction and AOF persistence, and ideally gets backed up like any other database, because at that point, it is one.
The question worth asking periodically
For any Redis instance that's been running a while: if it disappeared right now, would anything be permanently lost, not just slow? If the answer is no, the cache configuration is correct and there's nothing to change. If the answer is yes, even for one key pattern, that's a database now, whether or not anyone decided that on purpose, and it's worth configuring, monitoring, and backing up like one before that question gets answered the hard way.