Advertisement
Redis tends to enter a project incredibly quietly. Someone drops it in to cache a painfully slow database query, configures it with the absolute defaults, and moves on.
Eighteen months later, that exact same instance is also holding active user sessions, rate-limiting counters, feature flag states, and a background job queue or two. Absolutely none of those things were ever written to a permanent database first. The Redis instance itself did not change. What it is blindly being trusted to do did change, and the configuration almost never caught up.
Cache mode: Losing the data is fine by design
When Redis is genuinely functioning solely as a cache, every single key in it is a temporary copy of something that exists somewhere else, or it is the compute cost of regenerating it.
If Redis completely restarts and the cache is wiped clean, the application is noticeably slower for a bit while it repopulates, but nothing is permanently lost. For this specific case, the correct configuration actively embraces that reality:
maxmemory 2gb
maxmemory-policy allkeys-lru
save ""
maxmemory-policy allkeys-lru means that the second Redis hits its hard memory limit, it aggressively evicts the least-recently-used keys to make room for new ones. That is exactly the right behavior for a cache. save "" disables RDB snapshotting entirely. There is absolutely nothing here worth the disk I/O of persisting, since everything is 100% reconstructable.
Database mode: Losing the data is a real incident
The exact moment Redis holds something with no other source of truth—a user session that logs out a customer if lost, a queue of background jobs that haven't been processed yet, or a critical counter that resets unexpectedly—the entire calculus flips completely.
Now, allkeys-lru is actively dangerous. Redis can and will decide to silently evict a user's active session token just to make room for a random cache entry. That is not a performance hiccup; that is direct data loss. The configuration must match the new reality:
maxmemory-policy noeviction
appendonly yes
appendfsync everysec
noeviction means Redis forcefully returns a hard error on writes once memory is completely full, rather than silently deleting something. This brutally forces you to notice and actually fix a capacity problem instead of quietly losing critical data. appendonly yes enables the append-only file (AOF) for rock-solid persistence, with everysec perfectly balancing durability against write performance. You lose at most one second of writes on a hard crash, rather than everything since the last RDB snapshot.
The actual danger is mixing both unintentionally
The riskiest setup is not "cache" or "database." It is running both in the exact same instance, under a configuration chosen exclusively for one of them.
Running allkeys-lru with both disposable cache entries and critical session tokens in the exact same keyspace means Redis literally cannot tell the difference between a cache entry that is perfectly fine to lose and a session that absolutely isn't. It evicts whatever is least recently used, which might be either. I have personally seen this cause an intermittent "users randomly get logged out under load" bug that took days to trace back to cache pressure evicting session keys, simply because nothing about the symptom pointed directly at Redis's eviction policy.
Separating them does not mean separate servers
Redis absolutely supports multiple logical databases on one single instance (SELECT 0 through SELECT 15 by default). However, these completely share the exact same maxmemory limit and eviction policy, so they do not actually solve this problem at all.
What actually works is running two completely separate Redis instances, even on the exact same host, each with a configuration perfectly 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 zero persistence. The store instance gets noeviction and AOF persistence. Ideally, it also gets backed up exactly like any other database, because at that point, it legally is one.
The question worth asking periodically
For any Redis instance that has been running for a while, ask this: If it violently disappeared right now, would anything be permanently lost, rather than just slow?
If the answer is a hard no, the cache configuration is correct and there is nothing to change. If the answer is yes, even for one single key pattern, that is a database now. Whether or not anyone decided that on purpose, it is worth configuring, monitoring, and backing up exactly like a database before that question gets answered the hard way.
Advertisement