Eventual consistency means replicas may briefly disagree after a change, but the system works toward the same correct state over time. This trade-off favors availability, scalability, and fault tolerance over immediate total correctness. section 1.1.3 section 8.1
In a replicated cluster, a row is stored on multiple nodes. If every replica cannot respond immediately, a query can still succeed depending on its consistency level; that flexibility can expose temporarily inconsistent results while replicas converge. section 1.2.1
Consistency levels make the availability-versus-consistency choice concrete for a key with three replicas:
- ALL requires all three replicas to acknowledge a request. It provides the strongest option shown, but tolerates no node failure. section 1.2.1
- QUORUM requires a majority: two of three replicas. It tolerates one failed node while requiring most replicas to participate. section 1.2.1
- ONE requires one replica. It tolerates two failures, but makes inconsistent results more likely. section 1.2.1
Choosing a quorum
With three replicas, requiring QUORUM for both reads and writes means two replicas acknowledge each operation. If one node is unavailable, the other two can continue serving traffic; the majority participation prevents inconsistent data under the stated read-and-write pattern. section 1.2.1
This is a softer BASE model rather than relational ACID guarantees. The reduced validation needed for immediate correctness supports faster writes, but developers must design with weaker consistency in mind. section 1.2.2
Table 1.1 Sample of consistency level options, assuming a cluster with three replicas
|
Consistency level
|
Description
|
Number required to succeed
|
Failures tolerated
|
|---|---|---|---|
ALL
|
Requires all replicas to succeed
|
3
|
0
|
QUORUM
|
Requires a majority of replicas to succeed
|
2
|
1
|
ONE
|
Requires a single replica to succeed
|
1
|
2
|
Compare ALL, QUORUM, and ONE by required acknowledgments and tolerated failures for a three-replica cluster. section 1.2.1
