Good morning all. Hypothetical Setup: 1 data center RF = 3 Total nodes > 3 Problem: Suppose I need maximum consistency for one critical operation; thus I specify CL = ALL for reads. However, this will fail if only 1 replica endpoint is down. I don't see why this fail is necessary all of the time since the data could have been updated since the node became unavailable and it's data is old anyways. If only one node goes down and it has the key I need, then the app is not 100% available and it could take some time making the node available again. Proposal: If all of the *available* replica nodes answer the read operation and the latest value timestamp is clearly AFTER the time the down node became unavailable, then this situation can meet the requirements for *near* 100% consistency since the value in the down node would be outdated anyway. Clearly, the value was updated some time *after* the node went down or unavailable. This way, you can have max availability when using read with CL.ALL... or something CL close in meaning to ALL. I say "near" 100% consistency to leave room for some situation where the unavailable node was only unavailable to the coordinating node for some reason such as a network issue and thus still received an update by some other route after it "appeared" unavailable to the current coordinating node. In a situation like this, there is a chance the read will still not return the latest value. So, this will not be truly 100% consistent which CL.ALL guarantees. However, I think this logic could justify a new consistency level slightly lower than ALL, such as ALL_AVAIL. What do you think? Is my logic correct? Is there a conflict with the architecture or base principles? This fits with the tunable consistency principle for sure. Thanks for listening