TopolearnEvery modeling and consistency rule in Cassandra follows from its distributed, masterless design.
Cassandra is a distributed database where all nodes are equal: there is no primary, so any node can accept reads and writes and there is no single point of failure. Nodes form a cluster, optionally spread over several data centers.
Data is organised into partitions. Each row belongs to a partition identified by its partition key; Cassandra hashes that key (Murmur3) to a token, and the token range each node owns decides where the partition lives. Every partition is stored on several nodes, the replication factor (typically 3), so the cluster survives node failures. Adding nodes spreads the token ranges and capacity grows roughly linearly.
The client sends a request to any node, which becomes the coordinator and forwards it to the replicas. You choose per request how many replicas must answer (the consistency level), trading latency and availability against consistency.
Design consequences:
- reads are efficient when they hit one partition, and there are no joins and no ad-hoc queries across all data,
- writes are extremely cheap (append-only), so you duplicate data into one table per query,
- availability is favoured over strict consistency; in CAP terms Cassandra is usually described as AP with tunable consistency.
Cassandra is a good fit for large write-heavy datasets with known access patterns: time series, event logs, messaging, IoT, user activity.
Remember
- All nodes are equal; any node can coordinate a request
- Rows live in partitions placed by hashing the partition key to a token
- Each partition is replicated to RF nodes, typically 3
- Fast single-partition access, no joins: model per query
Watch out for
- Choosing Cassandra for ad-hoc analytics or relational data with many joins.