[a-robinson]

WAN-optimized consensus protocols like Mencius and Egalitarian Paxos indeed are better for writes because any node can commit a write in one round trip, but they don't allow for reads with zero round trips. Every read must go through the consensus machinery in order to ensure consistency, whereas in CockroachDB the leaseholder can serve reads without needing to consult other nodes.

[toolslive]

why do reads have to go through the consensus machinery ? If they don't go through the machinery, read results will still be consistent, they just might not include the very last updates, but you cannot avoid that. Raft has the same problem (they all have, and it's unavoidable): suppose you read from the Leader (Master, whatever you call it); the leader sends you a perfect fresh consistent value; however, your network takes time to deliver it to you and meanwhile an update might have happened. It just shows that the key value store should provide atomic multi updates (or at least compare-and-swap )

[cube2222]

Without the consensus read you can get inconsistent values.

Suppose you write value a to leader A and then value b to leader A. Node B got both updates, node C got only the a value because of network timeouts.

Now you do a read from B of both values, you get the current a and b. Then you do a read from C, you receive the current a and the old b. Inconsistent.

Basically a violation of serializability and linearizability across the cluster in respect to the client.

[toolslive]

No. In your example, value 'a' will not have been applied to the store in C yet, as there is a hole in the log: a set of updates that contains update 'b' (and possibly others). So the view in A will be more up to date than the view in C, but both will be consistent.