Replication Factor, Quorum & Tunable Consistency

In this chapter

We'll meet replication factor, the real CONSISTENCY statement, and tunable consistency — ONE, QUORUM, and ALL as a real, per-query trade-off between speed and certainty, plus what "eventual" actually means in eventual consistency.

9–11 min

The Problem in Real Life

GreenMart decides every truck event should be stored on three different nodes, not one — a single machine dying should never mean a lost delivery record. Sarah sets that up in minutes. Then Mike asks the harder question: when GreenMart reads a truck's current status back, how many of those three copies actually have to agree before the answer is trusted?

"All three, obviously," Mike says. Sarah points out that waiting for all three, every single time, means one slow or unreachable node can stall every read — and for most of GreenMart's questions, that's a worse trade than occasionally reading data that's a moment behind.

It's not one answer for the whole database. It's a choice we get to make, per question.

Sarah

One Fixed Guarantee vs. A Trade-Off Chosen Per Query

Replication factor sets how many copies

RF 3 means every row lives on three separate nodes — set per keyspace, a durability decision independent of any single query.

Consistency level sets how many must agree

ONE, QUORUM, or ALL — how many replicas must respond before an individual read or write counts as successful.

Tunable, per query

Not one fixed guarantee for the whole database — a routine write can use ONE, a critical read can demand QUORUM or ALL.

Eventual consistency is a bounded window

A low-consistency write may briefly lag on some replicas, but every replica converges on the same value — not an abandoned promise.

Replication means Cassandra keeps more than one copy of each row, on different nodes, so losing one machine never means losing data. The replication factor (RF) is simply how many copies — RF 3 means every row lives on three separate nodes. This is set per keyspace, so different keyspaces can make different durability trade-offs.

A consistency level is the real, separate decision this chapter is actually about: for any single read or write, how many of those replicas have to respond before Cassandra calls the operation successful? ONE means just one replica has to answer — fast, but a moment behind is possible. QUORUM means a strict majority of replicas (with RF 3, that's 2 of 3) have to agree — the everyday default, balancing speed and safety. ALL means every replica must respond — the strongest guarantee, and the slowest, since one unreachable replica blocks the whole operation.

CONSISTENCY <LEVEL> is real CQL — it sets the level for whatever statements run next in the same session, and can be changed as often as needed. Here, a fast-and-loose ONE write for a routine location ping, then a stricter QUORUM read for a status check that actually matters.

Tunable Consistency — Real Syntax, Chosen Per Query

CREATE TABLE truck_events (
  truck_id text,
  event_time text,
  speed_kmph int,
  PRIMARY KEY (truck_id, event_time)
);

CONSISTENCY ONE;
INSERT INTO truck_events (truck_id, event_time, speed_kmph) VALUES ('truck-01', '2026-09-02T09:00:00', 42);

CONSISTENCY QUORUM;
SELECT * FROM truck_events WHERE truck_id = 'truck-01';

This simulator has exactly one in-memory replica, not a real multi-node cluster — so every level here returns the same, fully up-to-date result. The syntax is genuinely real CQL, shown for what it looks like; the actual quorum trade-off only becomes visible against a real, multi-node cluster.

Tunable consistency is the name for this whole idea: unlike a system that hands down one fixed guarantee for every operation, Cassandra lets GreenMart choose the trade-off per query — a routine sensor ping can use ONE for speed, while a payment-adjacent read can demand QUORUM or higher. This is the same Consistency-vs-Availability trade-off Act 1's CAP theorem chapter introduced in the abstract, and Act 4's eventually-/strongly-consistent DynamoDB reads made concrete for one product — Cassandra just hands GreenMart the dial directly, on every single read and write, instead of picking one setting for the whole database.

One more term worth knowing by name: eventual consistency. If GreenMart writes with a low consistency level, it's possible — briefly — for a read elsewhere to see an older value, until the write finishes propagating to every replica. That propagation isn't instant, but it isn't indefinite either: left alone, every replica eventually converges on the same value. "Eventual" describes a real, bounded window, not a promise abandoned.

Key Takeaway

Consistency isn't one fixed setting for the whole database — it's tunable, per query: ONE for speed, QUORUM as the everyday balance, ALL for the strongest guarantee, each one a real, deliberate trade against replication factor and how sure a given answer actually needs to be.

Why This Matters

Every write and every read GreenMart runs from here forward carries this choice, explicitly or by default. The failure-handling chapter ahead depends directly on this: how gracefully the fleet-tracking system survives a dead node is really a question of whether the chosen consistency level can still be satisfied with one fewer replica available.

GreenMart can now choose, deliberately, how sure a read needs to be. None of this explains what a node is physically doing on disk when a write or a read actually happens, though — that's exactly where the next chapter goes.