We should really push CAP consistency concerns to the client. Let's say transactions are committed to a distributed log (ala raft), then the log position can b

We should really push CAP consistency concerns to the client. Let's say transactions are committed to a distributed log (ala raft), then the log position can be the transaction id. Passing the transaction id back to the client will then allow it to choose its own level of consistency by: 1. Pick consistency over latency: Make read request with transactions id to a random node, and the node wait until it has caught up that point in the distribute log before responding 2. Pick latency over consistency: Make read request for whatever is latest data on random node Note how this is a departure from how raft services client reads. In raft land only the primary is allowed to service reads as it waits for other consensus tick to ensure it is still the leader before responding. While this guarantees consistency, it hurts scalability as you now have a single bottleneck serving all clients for BOTH read/writes.