Comparison of Consistency Read Implementations in Consul and etcd

etcd and Consul are popular distributed consistent key‑value stores; this article shares and compares the implementations of their consistency reads.

1 Consul Consistency Read Implementation

Consul provides three read modes:

default

consistent

stale

"stale" is non‑consistent, while "default" and "consistent" are consistent reads. The difference is that "consistent" verifies the node is still the Leader before reading to avoid returning stale data.

The implementation starts in the Get method, which first calls ForwardRPC to forward the RPC request; if forwarding succeeds, the result is returned directly.

If forwarding does not complete, the method invokes blockingQuery to query the local store for the result.

The internal ForwardRPC logic performs three main actions:

If needed, forward the request to other data centers.

Determine whether the current node can handle the read request.

If it cannot, forward the request to the Leader.

Consul decides whether a request is a consistent read by checking info.IsRead and info.AllowStaleRead . When the HTTP parameter AllowStale is false , the request is treated as a consistent read, which then triggers step 3 to forward the request to the Leader (if the current node is not the Leader).

Summary of Consul

Consul achieves consistency reads by forwarding the request to the Leader node.

2 etcd Consistency Read Implementation

etcd supports two read modes: Serialize (serial read) and Linearizable (consistent read). Linearizable reads are the consistent mode.

In a linearizable read, etcd first calls linearizableReadNotify , which signals s.readwaitc and waits for a result.

The signal is processed in the linearizableReadLoop method, which invokes requestCurrentIndex to send a MsgReadIndex message to the Leader and obtain the Leader’s current committed index ( confirmedIndex ).

etcd then compares the local appliedIndex with confirmedIndex . If the local index is behind, it waits until it catches up, after which nr.notify clears the wait on linearizableReadNotify and the serial read proceeds.

Thus, etcd’s consistent read first fetches the latest committed index from the Leader, waits for the local store to apply up to that index, and only then returns the read result.

3 Overall Summary

Consul’s consistency‑read implementation is simpler and more direct but may put additional load on the Leader node.

etcd’s implementation is more complex, leveraging each node’s resources to achieve consistency.

References

[1] etcd: https://etcd.io/

[2] Consul: https://www.consul.io/