[DanWaterworth]

> We use Raft only to determine a consistent configuration. The queries themselves are executed in the same efficient way as before.

So, you've made the noob mistake in using Raft, where only configuration goes in the log and actual changes to data aren't replicated in the same manner.

[danielmewes]

We have carefully designed the way data is versioned and replicated in RethinkDB 2.1 to result in a correct and consistent system in combination with the Raft-supported configuration management. For example we make sure that both components use consistent quorum definitions and the same membership information at any point.

This allows us to provide different degrees of consistency guarantees for the data, depending on the user's need. Our default is already pretty conservative, but allows uncommitted data to be visible by reads. In the strongest consistency mode, RethinkDB 2.1 provides full linearizability (see http://docs.rethinkdb.com/2.1/docs/consistency/ for details). We have confirmed this both theoretically as well as by testing the overall system using the Jepsen test framework.

[DanWaterworth]

What do you gain? Let's say that you're right and you've managed actually managed to provide the guarantees that you say you have. By adding things to Raft, you haven't made it simpler and, having implemented Raft myself recently, I can attest that it's not the simplest of things to start with.

If you're looking for different degrees of consistency, I'm fairly sure you can do that without protocol level changes to Raft.