Summary

Evidence

• ·Cassandra's partitioner (Murmur3) maps partition keys to tokens on the consistent hash ring
• ·Adding a node to a Cassandra cluster only requires streaming ~1/N of total data (where N is node count): linear scaling
• ·Vnodes ensure each new node absorbs token ranges proportionally: no hotspot from token assignment
• ·Replication factor copies token ranges to N consecutive nodes on the ring: deterministic without central coordination
• ·{'DataStax documentation states': 'Cassandra uses consistent hashing to minimize the amount of data that must be reorganized when nodes join or leave'}

Operational Context

• ·RF (replication factor) must be set before data insertion: changing RF requires a full repair operation
• ·nodetool ring shows the current token distribution: useful for diagnosing uneven data distribution
• ·nodetool decommission triggers token range transfer using the consistent hash ring

Tradeoffs

• ·Consistent hashing in Cassandra means partition key must be chosen for distribution, not range queries
• ·RF=3 across 3 AZs is recommended: RF determines the quorum read/write requirements
• ·Token imbalance (despite vnodes) can occur if node sizes are heterogeneous: use DataStax OpsCenter for monitoring

Evidence grounding

Consistent hashing is built into Cassandra's core design, documented in the original Cassandra paper and all versions of Cassandra documentation. The benefit is structural: not a configuration choice.