Design around bounded partitions and known queries#
Cassandra fits distributed, write-heavy or multi-datacenter workloads when queries can be shaped around partition keys and clustering order. “We have lots of data” is not enough. Review wide-column modeling first.
Partition keys locate data; clustering columns order within it#
Conversation-scoped message history
partition key = conversation_id
clustering key = message_time
Efficient: fetch recent messages for one conversation.
Risk: an enormous long-lived conversation creates a huge/hot partition.Query-driven tables often duplicate data for different access patterns. That is intentional only when propagation and consistency are owned.
Coordinator, token ownership, and replicas#
Cassandra uses hash-based token ownership and replicates partitions according to the keyspace strategy and replication factor. Nodes can coordinate requests even when they do not own the target partition.
A changing hash ring
Keys belong to the next node clockwise. Add or remove a node to see which sample keys actually move.
| Key | Position | Owner |
|---|---|---|
profile:42 | 4 | Node A - unchanged |
video:91 | 18 | Node B - unchanged |
feed:17 | 37 | Node B - unchanged |
image:63 | 57 | Node C - unchanged |
session:8 | 72 | Node C - unchanged |
post:29 | 91 | Node A - unchanged |
The ring visual isolates the ownership concept. Cassandra adds token ranges, replicas, topology-aware placement, and operational details beyond this generic model.
Tunable consistency changes the acknowledgement set#
Per-operation consistency levels determine how many appropriate replicas must respond. Under assumptions, overlapping read and write quorums - often summarized as R + W > N - can make a completed write visible to a later read. That arithmetic alone does not prove universal linearizability, protect against clock-dependent conflict resolution, or describe every multi-datacenter case.
Convergence has operational machinery#
Replication supports availability while replicas can temporarily diverge. Hinted handoff, read repair, and anti-entropy repair help convergence at different points. Compaction reconciles storage files; deletes create tombstone state that must propagate and later be reclaimed. Interview depth is why repair and bounded partitions matter, not tuning compaction internals.
Cassandra vs DynamoDB#
| Cassandra tendency | DynamoDB tendency |
|---|---|
| Open, self-managed distributed database ecosystem and direct operational control | Managed AWS service with service-defined operations and APIs |
| Tunable consistency and explicit cluster topology | Table/index read-consistency options and managed partitioning |
| Team owns repair, capacity, upgrades, and topology | Team owns key/access design while AWS owns more infrastructure operations |
- Choosing Cassandra because the dataset is “big.”
- Modeling like normalized relational tables.
- Creating unbounded or hot partitions.
- Claiming quorum arithmetic always yields linearizability.
- Ignoring repair, tombstones, compaction, and operational ownership.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Which query determines the partition and clustering keys?
- How large can one partition become?
- Which consistency level serves each operation and why?
- What happens when replicas diverge?
- Why operate Cassandra instead of using DynamoDB or PostgreSQL?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Cassandra Dynamo architectureApache Cassandra Documentation
- Cassandra data definition and partition keysApache Cassandra Documentation