Reads in Raft

26 Jun 2019

Writes are inserted into the raft log; there is a total order of writes. But what about reads?

Let’s look at Consul. Consul offers three consistency levels:

In all cases, reads are not inserted into the log. Several problem can arise.

Problem 1: there could be uncommitted writes which were received before the read. These writes arrived before the read but haven’t made it through the raft protocol yet. This means we get stale reads. If reads went through the raft protocol we’d avoid this issue (this is a trade-off, the read would be correct but it’d be much slower). This applies to the consistent consistency level.

Problem 2: there could be committed writes that the current node doesn’t know about. Problem 2a: a node assumes it’s the leader, but it’s not, and services reads. This applies to the default consistency level. Problem 2b: the follower hasn’t learned about a write yet. This applies to the stale consistency level.

There are potential problems in each consistency level of Consul. I believe there is room for a reflective consistency solution for users that can accept some level of anomalies. They would then be able to describe their ideal anomaly rate and the system would then adapt its consistency level to accommodate.

View on GitHub