Redis works great as a cache, but there are a few things you need to do in order to use it reliably as a cache.

1) Wrap your client library so that it's impossible to store anything without an expiry date. You don't want 6-months-old data suddenly coming up in your app!

2) Either turn off persistence, or use a separate database for the cache. In other words, don't mix volatile data with stuff you actually care about.

3) Set up a reasonable maxmemory value with an appropriate maxmemory-policy, so that Redis doesn't eat up all your RAM.

4) Resist the urge to use complex data structures. If you try to update a single field on an expired hash, you will end up with an incomplete object.

If you don't want all that hassle, then yes, Memcached probably works better out of the box.

▲

dvt 2 hours ago | parent [-]

> 1) Wrap your client library so that it's impossible to store anything without an expiry date. You don't want 6-months-old data suddenly coming up in your app!

No need for this client-side complexity, as you should be using `allkeys-lru`. FWIW, should likely be doing this anyway, as (generally speaking) all data stored in Redis is usually regarded as volatile because of what Redis actually is.

▲

kijin an hour ago | parent [-]

> as (generally speaking) all data stored in Redis is usually regarded as volatile because of what Redis actually is.

If you know this already, then you didn't need to read OP or any of this thread. :)

The problem is that Redis tries very hard to position itself as a persistent data store, with defaults that lean toward persistence (no default eviction policy). Beginners need to fight these defaults every step of the way if all they want is a cache.

	▲	dvt 25 minutes ago \| parent [-]
		> The problem is that Redis tries very hard to position itself as a persistent data store What are you talking about? On their website, the top 3 use cases (under the Platform menu) are: caching, streaming, and session management. Literally all of these three are volatile.