Cassandra Replication

Replication is the process of storing multiple copies of the same data on different nodes. It is Cassandra's primary mechanism for fault tolerance and high availability. When a node fails, reads and writes continue seamlessly because other nodes already hold copies of the data.

The Notebook Analogy

Imagine you write every important note in three identical notebooks and keep each notebook in a different building. If one building burns down, you still have the other two. Cassandra does exactly this with data — it writes every piece of data to a configurable number of nodes so that node failures never cause data loss.

Replication Factor

The replication factor (RF) tells Cassandra how many copies of each piece of data to store. You set the replication factor at the keyspace level when you create or alter a keyspace.

CREATE KEYSPACE ecommerce
  WITH replication = {
    'class': 'NetworkTopologyStrategy',
    'us_east': 3
  };

Replication Factor Examples:

RF = 1:  [Node A: copy 1]
         → One failure = data lost

RF = 2:  [Node A: copy 1] [Node B: copy 2]
         → One failure = still available

RF = 3:  [Node A: copy 1] [Node B: copy 2] [Node C: copy 3]
         → Two failures = still available
         → Most common production setting

How Replication Works on the Ring

When Cassandra writes a row, the coordinator hashes the partition key to find the primary node. It then places additional copies on the next nodes clockwise around the ring until it has placed RF copies total.

Ring with 6 nodes (A → B → C → D → E → F → A)
RF = 3, data hashes to Node B:

  Primary copy  → Node B
  Replica 1     → Node C
  Replica 2     → Node D

If Node B goes offline:
  Reads and writes route to Node C and Node D instead.

SimpleStrategy

SimpleStrategy places replicas on the next nodes in the ring, clockwise, without regard to racks or data centers. Use it only for single data center clusters or development environments.

CREATE KEYSPACE dev_keyspace
  WITH replication = {
    'class': 'SimpleStrategy',
    'replication_factor': 3
  };

NetworkTopologyStrategy

NetworkTopologyStrategy places replicas across different racks within a data center and across multiple data centers. This is the correct choice for any production deployment.

CREATE KEYSPACE prod_keyspace
  WITH replication = {
    'class': 'NetworkTopologyStrategy',
    'us_east': 3,
    'eu_west': 2
  };

NetworkTopologyStrategy placement:

US-East data center (RF=3):
  Rack 1: Node A (primary)
  Rack 2: Node C (replica)
  Rack 1: Node E (replica — different from primary rack)

EU-West data center (RF=2):
  Rack 1: Node G
  Rack 2: Node H

Hinted Handoff

When a replica node is down during a write, the coordinator stores the write as a "hint" and delivers it to the offline node when it comes back online. Hints are stored for a limited time (default 3 hours). If the node is down longer than that, you need to run a repair to reconcile the missing data.

Write with Node C offline:

Coordinator sends write to:
  Node A ──▶ write stored ✓
  Node B ──▶ write stored ✓
  Node C ──▶ OFFLINE
    ↳ Coordinator stores hint for Node C

Node C comes back online:
  Coordinator delivers hint ──▶ Node C now up to date ✓

Read Repair

When a read query contacts multiple replicas and detects that some hold outdated data, Cassandra automatically sends the correct version to the stale replicas. This background process keeps replicas in sync without requiring a full repair operation.

Read with RF=3, consistency level QUORUM:

Coordinator asks Node A, Node B, Node C
  Node A returns: {name: 'Alice', email: 'alice@new.com'} (timestamp: T2)
  Node B returns: {name: 'Alice', email: 'alice@old.com'} (timestamp: T1)
  Node C returns: {name: 'Alice', email: 'alice@new.com'} (timestamp: T2)

Result: T2 wins (most recent). Node B receives a background repair.

Choosing the Right Replication Factor

Use Case                     Recommended RF
──────────────────────────────────────────────────────────────
Local development            1 (no redundancy needed)
Single DC — low criticality  2
Single DC — standard prod    3
Multi-DC active/active       3 per data center
Highest criticality          5+ across multiple DCs

Replication and Consistency

Replication and consistency levels work together. A consistency level tells Cassandra how many replicas must acknowledge a read or write before it is considered successful. With RF=3 and consistency QUORUM, two out of three replicas must respond. This allows one node to be down while maintaining strong consistency guarantees.

Changing the Replication Factor

You can change a keyspace's replication factor at any time using ALTER KEYSPACE. After changing it, run a repair so Cassandra distributes data to the newly required replicas.

ALTER KEYSPACE ecommerce
  WITH replication = {
    'class': 'NetworkTopologyStrategy',
    'us_east': 5
  };

-- Then run repair:
nodetool repair ecommerce

Summary

Replication stores multiple copies of data across different nodes, racks, and data centers. The replication factor controls how many copies exist. SimpleStrategy works for development; NetworkTopologyStrategy is the production standard. Hinted handoff keeps writes safe when a node is temporarily offline, and read repair keeps replicas synchronized during reads. Choose RF=3 as your default starting point for production keyspaces.