That's why I think this is a design decisions in both cases: In one of this products (etcd if I remember correctly) there was a clear statement in the document

That's why I think this is a design decisions in both cases: In one of this products (etcd if I remember correctly) there was a clear statement in the documentation about this semantics, and anyway, who implements Raft knows that for reads to be consistent they need to go the same path as writes. In the Raft paper you can find a whole section about this. If you check the paper there are the following clearly stated informations: Leaders can't reply to read queries without doing additional checks otherwise the reads are not linearizable. For the reads to be linearizable, the following two things must be performed by leaders. 1) Commit a NOP at the start of its term, which is not a problem from a performance point of view. The problem is "2". 2) A leader needs to check if it is still the leader before every read, and this requires to contact a majority. That's the performance problem of linearizable reads, because you need to pay a latency equal to the latency of the slowest reply of the N/2+1 acks you need. However note that even linearizable reads don't require fsync() to be called, so they are still better than writes.