[rubiquity]

I would guess that Mike Perham's point of view is based on how Sidekiq uses Redis for persisting jobs. If you don't configure Redis properly and you use Redis as a job queue as well as a cache then you risk the problem of your job queue entries getting evicted depending on your Redis config/version of Redis you are using. That type of thing happening frequently would be very annoying for someone that made a job queue that uses Redis for persistence of jobs.

Caching web content can grow and grow until you run out of memory. If you aren't using Redis for data that can be easily regenerated, then go ahead and use Redis as a cache. But if you are, I think it will give you operational peace of mind to segregate where you store your background jobs and where you cache content.

[thezilch]

That makes zero sense. Why would you run them out of the same instance / with the same configuration? Mike is already running a second process for caching; he'd simply replace it with a different instance of Redis.

[rubiquity]

You're right. It doesn't make sense. Does that prevent tons of people from doing it? Nope.

[mperham]

Because users don't read docs. They don't understand these tools. They don't catch on that two completely different use cases require two completely different configurations and two completely different instances of Redis.