To me Redis has always seemed like a Trojan Horse for developers. The first impression is its this simple key-value database, so easy to use. Oh wait... it's al

To me Redis has always seemed like a Trojan Horse for developers. The first impression is its this simple key-value database, so easy to use. Oh wait... it's also a cache, nice! Let's cache all the things too! And look... all the cool kids are are using it too, so it must be cool, meanwhile the old Unix mantra of make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. ( http://www.catb.org/~esr/writings/taoup/html/ch01s06.html http://www.catb.org/~esr/writings/taoup/html/ch01s06.html ). Fast forward 10 years and you need to download it's Enterprise Whitepaper ( https://redis.com/solutions/use-cases/caching/ https://redis.com/solutions/use-cases/caching/ ) to make the right caching decisions. Where this is coming from is having worked on a project where Redis was being used as a database and a cache, on different ports. And of course most of the dev team hadn't read the the manual because Redis "is simple and just works". And of course someone forgot to actually configure the Redis instance that was supposed to be a cache to actually _be_ a cache. And someone else thought the instance that was supposed to be a cache but wasn't was actually a database. And yet another had used TTL caching to solve all their performance issues. And pretty soon mystery bugs start showing up but sadly no one can actually REASON about what the whole thing is doing any more, but there's no time to actually clean up the mess because it's a startup struggling to stay afloat. And I remember asking "why didn't you memcached for caching?" and the response was "Dude! No one is using memcached any more". So the technical decision for Redis was based on "what's cool right now". Anyway... I feel a bigger rant brewing so I'll stop here.