Cassandra Read Consistency ONE vs QUORUM for RF 3

Question

Goal: select a read consistency level for a three-node Cassandra 4.x cluster with replication factor 3 that serves user-profile reads. The application must avoid stale reads, but the p99 latency budget is tight.
Local single-node testing with consistency ONE hides replication lag because the only replica satisfies the read requirement. In production, ONE can return stale or missing data if the contacted replica is behind or down, especially during a network partition. QUORUM requires responses from two of three replicas, improving read-your-writes visibility, but increases latency and reduces availability when a node is unavailable.
Unresolved: whether the consistency and availability trade-off justifies QUORUM for all reads, or whether ONE with targeted read repair is acceptable for this workload.

Does a QUORUM read return the most recent write when writes are issued at consistency ANY?
Which level meets a sub-100 ms p99 read SLA while preventing stale reads during a single-node partition?
Can read repair reliably converge replicas after reads served at consistency ONE?

Tasadduq Burney · Answer

Direct answer
Use QUORUM for user-profile reads if avoiding stale reads during a single-node partition is mandatory. ONE is faster but can return stale or missing data when the contacted replica is behind or unreachable. QUORUM does not guarantee read-your-writes for writes issued at ANY unless the write has already reached a second replica.
Confirmed behavior for Cassandra 4.x, RF 3

A QUORUM read requires responses from two of three replicas and returns the latest value only when that value exists on at least two nodes.
A write at ANY may be accepted by one node and replicated asynchronously, so an immediate QUORUM read can still return an older value.
A ONE read during a single-node partition may contact the downed node or a lagging replica, violating the stale-read avoidance requirement.
Default read repair (read_repair_chance = 0.1) is probabilistic and asynchronous; it converges replicas over time but does not prevent stale ONE reads during a partition.

Latency and availability trade-off
QUORUM waits for two nodes, which raises p99 latency and reduces availability compared with ONE. With one node down, two replicas remain available, so QUORUM can still succeed. Whether it stays under a 100 ms p99 budget depends on inter-node latency and load, so it must be measured in the target environment.
Verification steps

Write a test key at consistency ANY with one node temporarily stopped.
Read the key at QUORUM and confirm whether the latest value appears only after replication to a second replica.
Read the same key at ONE while the node remains down and check for stale or missing data.
Measure p99 latency for ONE and QUORUM under realistic load using JMeter or the Cassandra stress tool.
Optionally set read_repair_chance to 1.0 to observe faster convergence, but treat it as background repair, not a consistency guarantee.

Assumptions and uncertainty
Assumptions: Cassandra 4.x defaults, replication factor 3 across three nodes, and read_repair_chance at 0.1. Uncertainty: production network latency, node load, and hardware can shift p99 results, so the 100 ms SLA cannot be confirmed without measurement.
Missing diagnostic detail
Provide the average round-trip latency between replicas. This determines whether QUORUM can realistically meet the sub-100 ms p99 SLA.

Cassandra Read Consistency ONE vs QUORUM for RF 3

1 answer

Direct answer

Confirmed behavior for Cassandra 4.x, RF 3

Latency and availability trade-off

Verification steps

Assumptions and uncertainty

Missing diagnostic detail

Your perspective belongs here.

0 question comments