Remix.run Logo
Consistency over Availability: How rqlite Handles the CAP theorem(philipotoole.com)
53 points by otoolep 7 days ago | 5 comments
nchmy 4 days ago | parent | next [-]

I wonder if there could be something between None and Weak...

Don't check if it's the leader, but rather check (ideally locally, via some sort of flag that is updated on writes - when it's going to be communicating with the cluster anyway) if it's still part of the cluster/quorum. If so, then read locally. If not... reject the request since it might be stale?

The idea is that it is stronger than None, but weaker than doing reads (or any communication at all at read-time) from the Leader.

otoolep 4 days ago | parent [-]

rqlite creator here.

What you're describing sounds like "none", but adding the "limit read staleness" requirement. That is described in the docs.

https://rqlite.io/docs/api/read-consistency/#limiting-read-s...

nchmy 3 days ago | parent [-]

Thanks! Yes that sounds more or less what I was thinking

rvcdbn 4 days ago | parent | prev [-]

I'm sure there's a reason but I would expect a system like this to use leader leases for local reads

otoolep 4 days ago | parent [-]

rqlite creator here -- it's on my list to examine, not clear to me if it would add much beyond what is offered today. But it might.