Two lines from redis.conf on one project:
maxmemory 2gb
maxmemory-policy allkeys-lru
Correct for a cache. Then sessions moved into the same instance, because Redis was already there. Then the job queue, same reason. One process, three tenants. This works until the day it does not.
Cache data is disposable by definition, and those two lines embrace that. Memory fills up, Redis evicts the coldest keys, the application rebuilds them on demand. Persistence is optional. After a restart a cold cache is an inconvenience, not an incident.
Now put a job queue next to it. A job is a promise: the email will be sent, the invoice will be generated. With allkeys-lru a memory spike can evict the queue key itself. The jobs do not fail. They vanish. No error, no log entry, just customers asking where the email is. Silent loss that looks exactly like a healthy system.
A queue wants noeviction, so writes fail loudly when memory is full, and AOF persistence, so a restart does not erase the promises. Sessions sit in the middle: losing them logs everyone out, unpleasant but survivable. Decide per project.
The fix is almost embarrassing. Two Redis instances. One for cache, LRU, no persistence. One for queues, noeviction, AOF. Redis is a single process that starts in milliseconds. A second instance costs one config file.
Before putting anything into Redis, ask whether you can lose it. Both answers are fine, as long as the config matches the answer.
I knew all of this when I put the queue on the cache instance. It was faster that day.