Cassandra Architecture and the Distributed Ring
This domain tests how Cassandra works as a masterless, peer-to-peer ring: how nodes discover each other, how data is placed on token ranges, and how coordinators, replicas, and storage engines cooperate. Expect questions on gossip, seed nodes, snitches, partitioners, virtual nodes, and the write/read path.
Ring mechanics
- Every node owns token ranges. Murmur3Partitioner is the default; RandomPartitioner is legacy; ByteOrderedPartitioner is rarely appropriate.
- Nodes exchange version, status, schema, and load through gossip. Seeds are contact points for joining, not a permanent single point of failure or a routing tier.
- A coordinator receives a client request, identifies replicas from the replication strategy and token map, and forwards requests. Any node can coordinate.
- Writes append to the commitlog and update the memtable; flushing produces immutable SSTables. Reads check the memtable, row cache if enabled, key cache, Bloom filter, partition index, then SSTables, merging by timestamp and tombstone rules.
- Hinted handoff, read repair, and repair provide anti-entropy; they are not substitutes for a backup.
Worked example
A 6-node cluster uses Murmur3, vnodes, and RF=3. A write at QUORUM needs 2 replica acknowledgements; a read at QUORUM needs 2 replica responses. Because R+W=4 > RF=3, the read set overlaps the write set, so a read is likely to see the latest write even if one replica missed it. With LOCAL_QUORUM in a multi-DC cluster, only replicas in the coordinator's DC count toward the quorum.
Traps
Treating seed nodes as masters; assuming all nodes must be seeds; using ByteOrderedPartitioner for range scans; expecting immediate consistency from hinted handoff; and confusing commitlog durability with SSTables persisted on disk.