The updates over the years have been useful and has tastefully kept with the true spirit of Redis - thanks for all your hard work Salvatore!
* Varnish (the "Notes from the architect" are a great read: https://www.varnish-cache.org/trac/wiki/ArchitectNotes)
* QEMU (actually, pretty much anything Fabrice Bellard has touched)
Redis code base is like a best-practice document.
* Gossip is used as previously to detect if an instance is down.
* The Raft algorithm leader election step is performed to get elected to perform the failover.
* The Raft epoch of the election is used as a version of the new configuration.
* New configs are always broadcasted via Pub/Sub in the master and all the known slaves. So every Sentinel is listening for configs with an epoch that is greater than the current config, to update its view of the cluster.
* Now Sentinels try to force the cluster to have the setup of the latest config in memory (but with some delay to try to receive updates). So for instance slaves replicating with a wrong ip/port are reconfigured and so forth.
* Finally Sentinels persist their state on disk at every configuration update, or every time a new slave or sentinel is added to a master, so the system model is much more reasonable. Redis instances when reconfigured are sent a "CONFIG REWRITE" as well. TLDR: process restart friendly.
In general the code is now much simpler. The state, as you understand from the above description, is eventually consistent with a last-config-win semantics (where last means the configuration with the greater epoch).
However built in support for bloom filters and range queries in sorted sets are two random examples of things that could get implemented in the future.
That is just how you put it. No where did i whine nor ignore the work the Redis Team did. Cluster being the one features that Redis will truly take off. As it currently isn't as popular as it should be.
Basically a swiss-army knife that you don't want to be without when developing high performance systems.
Then on the next slide, it added an arrow pointing at Batman's utility belt, and labeled it "Redis".
I know other people use it as their primary database or, on the other end of the spectrum, as an in-memory replacement...it can be configured optimally for those settings too.
It's powerful and flexible enough that I've used it as a primary datastore for the back-end to a web/multi-platform app/service. I don't necessarily recommend that, but it does work and is blazing fast and extremely reliable.
It's definitely some-assembly-required, though -- transactions aren't free, you have to do a little work yourself (on the upside, you always know what it's doing).
Also, it is intended to be used with the entire dataset in RAM. You can let it swap to some extent, but... don't. If your dataset is huge, you need something else.
 Actually, this is less true post-2.6 with lua scripts. I should play with those more, the bulk of the code I wrote that uses Redis was built in the 2.0-2.2 timeframe.
I've heard wonderful things, but I've also heard that you can easily abuse Redis for things that aren't appropriate.
I just got this
SSL connection error
Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.
That said I continue to use redis extensively, for storing data for dynamic websites (in preference to MySQL etc) and as a persistent cache for spam-testing, etc.
This may have changed with Lua scripting in Redis since now more advanced operations are scriptable, but until I see some good examples, it's beanstalkd for me =].