Replication Strategies: SimpleStrategy vs NetworkTopologyStrategy

Learn how Cassandra places replicas across nodes and datacenters using pluggable replication strategies.

A replication strategy is a keyspace setting answering two questions: how many copies of each row, and which machines hold them.

SimpleStrategy is like photocopying a document and handing copies to the next few people in line, regardless of which building they work in. NetworkTopologyStrategy is like deliberately sending copies to different offices in different cities so a single building fire can't destroy every copy.

Key Concepts

SimpleStrategy walks the ring. Put the first copy on the node that owns the token, then the next RF-1 nodes clockwise. It knows nothing about racks or datacentres.

RF-1

That is fine on a laptop and dangerous in production. The next two nodes round the ring may sit in the same rack, on the same switch, on the same power feed — so one rack losing power takes all three copies of some rows.

NetworkTopologyStrategy knows where the machines are. You give it a replication factor per datacentre:

    CREATE KEYSPACE shop WITH replication = {
      'class': 'NetworkTopologyStrategy',
      'mumbai': 3,
      'virginia': 3
    };

Six copies in total, three in each datacentre, and within a datacentre it walks the ring placing each replica in a different rack where it can:

    rack 1   node A  <- replica 1
    rack 2   node D  <- replica 2       one rack failing costs
    rack 3   node G  <- replica 3       exactly one replica

That per-datacentre number is also what makes LOCAL_QUORUM possible: with 3 replicas locally, a local majority is 2, and no query needs to cross the ocean.

LOCAL_QUORUM

Use it everywhere, including single-datacentre clusters. It costs nothing there and you will not have to migrate later.

Racks must be configured, not guessed. Cassandra learns the topology from the snitch. Leave every node in the default rack and NetworkTopologyStrategy still places three copies — all in that one rack, giving you none of the protection while appearing correct.

Changing replication is not instant. Raising the replication factor tells Cassandra where copies should live. It does not create them.

    ALTER KEYSPACE ...        -- new rule takes effect
    nodetool repair           -- actually streams the data

Between the two, reads at the new higher consistency level can fail, because the replicas exist in the plan and not on disk. Raise it one step at a time and repair after each.

What the interviewer is probing.1. "Which should production use?" Probing: the answer. Stalls: "Either." Moves up: NetworkTopologyStrategy always — SimpleStrategy ignores racks and datacentres, so replicas can all land in one failure domain.

2. "How is the replication factor set?" Probing: the scope. Stalls: "Per cluster." *Moves up:* per keyspace, and per datacentre under NetworkTopologyStrategy.

3. "What does rack awareness buy you?" Probing: the mechanism. Stalls: "Nothing." *Moves up:* replicas are placed in distinct racks, so a rack failure does not take every copy.

4. "What happens if you change the replication factor?" Probing: the operation. Stalls: "It rebalances." Moves up: existing data is not moved automatically — you must run repair, or reads will miss data on the new replicas.