I don't want my cache to silently fail.

Clustering redis is not that hard even if you do it manually and I have only had to do it once.

I never use redis persistence and have a max size set with LRU or whatever the application requires.

With memcached I remember having to mess around the LD_LIBRARY path to link whatever python module I was using at the time

▲

crabmusket 2 hours ago | parent [-]

> silently fail

Mature ops would be tracking cache hit ratios right?

It sounds like memcached would be really good in a use case where you really just need an optional stateless pure cache with absolutely zero rope to hang yourself on. A use case where "cache hit ratio" is the goal, not "fiddly in-memory data store".

▲

tempest_ 2 hours ago | parent [-]

> Mature ops would be tracking cache hit ratios right?

Sure, and sentry integrates well with redis in python which is what I use primarily with redis.

I don't think memcached is bad, I just think its old and industry has moved to redis because it offers more while covering the previous use case.

Calling redis fiddly is a mischaracterization. For many use cases I have not had to think more than 30s to setup redis.

(also when I say redis I mean Valkey at this point, even if they are starting to diverge)

▲

hparadiz an hour ago | parent [-]

There's basically zero reason to use redis. Pretty much every rdbms like mariadb, postgres, etc is just as fast. So then why redis? It's basically needless complexity in your system.

▲

robotresearcher 38 minutes ago | parent | next [-]

Postgres etc are more complex than Redis, are they not?

Does your argument assume you already have a database, so you might as well use it for your cache mechanism?

▲

imp0cat an hour ago | parent | prev [-]

Security. More precisely, the ability to secure access to redis with a password.

	▲	hparadiz an hour ago \| parent [-]
		Okay but I can do that with any rdbms and I can secure memcached too lol. So what? How is redis better than a fixed length table in MySQL?