So to clarify, you see WAIT as a replication primative. It can be used as part of a larger scheme with a strong coordinator to provide strong consistency.
Yes, with a strong coordinator or with a distributed system that can provide similar guarantees. But currently there is no plan to add this in Redis Cluster. Three main reasons:
* Our main business is low latency, so very few will use synchronous replication.
* Redis cluster is composed of multiple master-slave systems that hold a subset of the key space each. This means that if you need a majority of replicas to promote a new master in order to achieve consistency, after a partition you end with different hash slots having the majority in different sides of the partitions perhaps.
* With the current weaker consistency guarantees Redis Cluster can elect a replica that is isolated by the others but is in the right side of the partition, where the majority of other masters are. Similarly you can have just two total nodes for every hash slot, a setup that I believe will be very used, and still get some availability if the master fails.
So the consistency premises and the tradeoff of Redis Cluster are not exactly compatible with strong consistency.
Is WAIT still a useful tool? I believe yes, if documented as such:
WAIT in the context of Redis Cluster / Sentinel is not able to provide strong consistency, but lowers the percentage of probabilities that a failure mode that results in data loss happens.
A trivial example, what happens if a client is partitioned away with just a master? Without WAIT there is a window of NODE_TIMEOUT to lose data, with WAIT there is not this problem in this specific failure scenario. There are still a number of failure modes for WAIT, but are a smaller number compared to the full set of failure modes that there are without WAIT, so practically it does not feature strong consistency but provides the user with a smaller probability of data loss.
Another example: manual failover for very important data of some kind. You may have 5 nodes and use WAIT 4 to always write everywhere and improve durability.
* Our main business is low latency, so very few will use synchronous replication.
* Redis cluster is composed of multiple master-slave systems that hold a subset of the key space each. This means that if you need a majority of replicas to promote a new master in order to achieve consistency, after a partition you end with different hash slots having the majority in different sides of the partitions perhaps.
* With the current weaker consistency guarantees Redis Cluster can elect a replica that is isolated by the others but is in the right side of the partition, where the majority of other masters are. Similarly you can have just two total nodes for every hash slot, a setup that I believe will be very used, and still get some availability if the master fails.
So the consistency premises and the tradeoff of Redis Cluster are not exactly compatible with strong consistency.
Is WAIT still a useful tool? I believe yes, if documented as such:
WAIT in the context of Redis Cluster / Sentinel is not able to provide strong consistency, but lowers the percentage of probabilities that a failure mode that results in data loss happens.
A trivial example, what happens if a client is partitioned away with just a master? Without WAIT there is a window of NODE_TIMEOUT to lose data, with WAIT there is not this problem in this specific failure scenario. There are still a number of failure modes for WAIT, but are a smaller number compared to the full set of failure modes that there are without WAIT, so practically it does not feature strong consistency but provides the user with a smaller probability of data loss.
Another example: manual failover for very important data of some kind. You may have 5 nodes and use WAIT 4 to always write everywhere and improve durability.
And so forth.