Data Distribution: Partitioning, Replication, Consistency, and Topology
This domain tests how Cassandra places replicas across tokens, racks, and data centers, and how consistency levels trade latency against replica acknowledgement.
Placement and quorum
- SimpleStrategy is for single-DC or development only. Production uses NetworkTopologyStrategy with a per-DC RF. Replicas are placed on distinct racks where possible, so RF=3 in a 3-rack DC tolerates one rack failure.
- Consistency levels count replica responses. ONE, TWO, and THREE are fixed counts; QUORUM is floor(RF/2)+1 based on the keyspace total RF; LOCAL_QUORUM uses the coordinator DC; EACH_QUORUM applies per-DC quorum semantics, commonly for writes. SERIAL is for lightweight transactions.
- Strong-ish read-your-write requires R + W > RF on the same replica set. For multi-DC, use LOCAL_QUORUM on both sides to avoid cross-DC latency while keeping local overlap.
- Topology changes, such as adding a DC, changing RF, or moving racks, require nodetool repair or rebuild to stream missing replicas.
Worked example
Two DCs, each RF=3. A write at LOCAL_QUORUM in DC1 needs 2 of 3 DC1 replicas. A read at LOCAL_QUORUM in DC1 also needs 2 of 3. Since 2+2>3, the local read and write sets overlap, so the read sees the latest local write. A global QUORUM would require 4 of 6 replicas and may wait on the remote DC.
Traps
Using QUORUM in a multi-DC cluster and blaming Cassandra latency; setting RF higher than the number of racks or nodes and assuming fault isolation; expecting ONE to be strongly consistent; and forgetting that consistency level does not repair old data, repair does.