The primary key encodes the query#
partition key: conversation_id
clustering key: message_timestamp + message_id
Query: recent messages for one conversation, ordered by timeThe partition key determines which rows live together; clustering columns order rows inside that partition. This can make bounded range reads efficient, but query flexibility is intentionally constrained by the key design.
A partition is both a locality benefit and a risk#
Grouping a conversation's messages gives local range access. A single enormous or extremely active conversation can create a hot, oversized partition, so time buckets or another workload-specific split may be needed.
- Designing tables around entities rather than exact queries.
- Using a low-cardinality or monotonically hot partition key.
- Assuming arbitrary filters will remain efficient.
- Creating one unbounded partition per customer or device.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Which query does this primary key serve?
- How large can one partition grow?
- Which key becomes hot?
- What new table or index supports the next access pattern?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Cassandra data definitionApache Cassandra Documentation
Reach this point to mark the lesson as read.