[tempest_]

I stopped using memcached a decade a go in favour of Redis and now use valkey.

Never felt the need to go back to memcached except when a legacy dependency needed it.

[jimbokun]

OK.

What do you think of the argument made in the article?

[tempest_]

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]

> 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_]

> 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]

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]

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]

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