Eventually Consistency demystified
In my crusade into the NoSQL world, Eventually Consistency is everywhere. I want to demystify this property a little bit here.
But let's begin with an example to have the same base for the discussion :
- Let "Node1", "Node2" and "Node3" be three nodes (servers) that are part of our distributed datastore.
- Let "User A", "User B", "User c" be three users wanting to read and write data in our fictive distributed datastore.
At time (2) the write call of "Node A" returns. But the replication of value "A" hasn't been completely propagate to "Node2" and "Node3".
At time (3), "User B" and "User C" will read value "A" from "Node1" and "Node2" respectively. "User B" got the latest value (because it reads the node which initiate the update), "User C" will read either the old or the new version of "A", but without any guarantee regarding what it will read.
In a future time (5), "User B" and "User C" re-read value "A" and then got the same value. At this point of time, the datastore is consistent.
Immediate Consistency
In a Immediate Consistency, opposing Eventually Consistency, the write call from "User A" should wait till the replication is done on other nodes before returning, and replica nodes ("Node2" and "Node3") should be synchronized to expose the new value at the same time.
Moreover, if "Node1" is unable to talk to "Node2", the write replication will probably fail then the write call from "User A" will fail.
As we can notice, Immediate Consistency is hard to scale (see two-phase commit or paxos algorithm), because it increases the latency of the writes and makes the system not redundant to failure.
Trade-off for scaling writes
Eventually Consistency is then a trade-off for scaling writes that seems reasonable in certain use-cases.
