Cassandra — Replication Factor & Tunable Consistency

NoSQL Foundations §2.1 showed that in a leaderless replication system, a write quorum of W replicas and a read quorum of R replicas are guaranteed to overlap on at least one node — and therefore guarantee the read sees the latest write — whenever W + R > N. Cassandra's consistency levels are that exact formula, exposed as two settings (one for reads, one for writes) you choose on every single query, rather than a fixed property of the cluster:

Level	Replicas that must respond	Notes
ANY	None need to be a real replica yet	Writes only — can be satisfied by a hinted handoff alone; weakest possible durability
ONE	1	Lowest latency, weakest read/write guarantee
TWO / THREE	2 / 3	Rarely used in practice
QUORUM	⌊RF/2⌋ + 1, counted across all datacenters	Strong, but a multi-DC cluster pays a cross-DC round trip
LOCAL_QUORUM	⌊RF/2⌋ + 1, counted within the coordinator's own datacenter	Strong within one DC, without the cross-DC latency cost
EACH_QUORUM	A quorum in every datacenter, independently	Writes only — strongest multi-DC guarantee, highest latency
ALL	Every replica	Strongest single guarantee — one slow or down replica blocks the whole request

(Cassandra also has SERIAL/LOCAL_SERIAL, reserved for its compare-and-set / lightweight-transaction feature — a separate mechanism from ordinary reads and writes, not covered here.)

With RF = 3, a QUORUM write (W = 2) plus a QUORUM read (R = 2) gives W + R = 4 > 3 — every read is guaranteed to overlap the latest write. A ONE/ONE pair gives W + R = 2, which is not greater than 3 — no such guarantee, but noticeably lower latency.

A wallet-balance adjustment is money. It needs the strong guarantee: QUORUM on the write and QUORUM on the read, satisfying W + R > N so a read is guaranteed to see the adjustment that just landed.

A "user viewed this product" event feeding a recommendation engine is not money — occasionally losing one, or reading a slightly stale count, costs nothing anyone will notice, and the whole feed is already eventually consistent by design (NoSQL Foundations, Chapter 01's BASE model). It can use ONE, trading the consistency guarantee for lower latency and higher write throughput.

// financial adjustment — needs the quorum overlap guarantee
SimpleStatement adjustBalance = SimpleStatement.builder(
        "UPDATE wallets SET balance = balance - ? WHERE wallet_id = ?")
    .addPositionalValues(amount, walletId)
    .setConsistencyLevel(ConsistencyLevel.QUORUM)
    .build();
session.execute(adjustBalance);

// activity event — speed matters more than every replica agreeing immediately
SimpleStatement logView = SimpleStatement.builder(
        "INSERT INTO product_views (product_id, user_id, viewed_at) VALUES (?, ?, ?)")
    .addPositionalValues(productId, userId, Instant.now())
    .setConsistencyLevel(ConsistencyLevel.ONE)
    .build();
session.execute(logView);

Both statements run against the same keyspace, same RF, same cluster — the consistency level is a per-query decision, not a cluster-wide one. That tunability, per query, is Cassandra's signature feature relative to databases where consistency is a single global setting.

SimpleStatement adjustBalance = SimpleStatement.builder(
        "UPDATE wallets SET balance = balance - ? WHERE wallet_id = ?")
    .addPositionalValues(amount, walletId)
    .setConsistencyLevel(ConsistencyLevel.QUORUM)
    .build();
session.execute(adjustBalance);

SimpleStatement logView = SimpleStatement.builder(
        "INSERT INTO product_views (product_id, user_id, viewed_at) VALUES (?, ?, ?)")
    .addPositionalValues(productId, userId, Instant.now())
    .setConsistencyLevel(ConsistencyLevel.ONE)
    .build();
session.execute(logView);

With NetworkTopologyStrategy and RF split across datacenters (say, 3 in dc1 and 3 in dc2, RF = 6 total), plain QUORUM is computed against the combined replica count across every datacenter — satisfying it can require waiting on an acknowledgment from a replica on another continent, adding real, physical round-trip latency to every request.

LOCAL_QUORUM restricts the quorum requirement to replicas in the coordinator node's own datacenter only. It gives you the same strong-overlap guarantee as QUORUM, but scoped to one datacenter, without paying a cross-DC round trip. This is why LOCAL_QUORUM (and LOCAL_ONE) are the practical default consistency levels for most multi-datacenter production Cassandra deployments — plain QUORUM/ONE are reserved for single-datacenter clusters, or for the rare case where a cross-DC-strength guarantee is genuinely required and worth its latency cost.