Apache Cassandra rewards teams that model data around the questions they need to answer. Unlike a relational database, you cannot bolt indexes on later and hope for the best — partition design is locked in at write time and shapes everything from latency to operational cost. Below are the principles we apply on every cluster we deliver.
1. Start from your queries, not your entities
List the access patterns your application needs — by user, by date range, by status, by region. Each pattern usually maps to its own table. It feels wasteful coming from a relational background, but Cassandra storage is cheap; latency is not. A schema with eight purpose-built tables almost always outperforms a single normalized one with secondary indexes.
2. Choose partition keys that distribute work
A partition key has two jobs: spread data evenly across the ring, and group everything you need to read together onto a single node. Cardinality matters — too low and you get hot partitions; too high and you lose the locality benefit. For multi-tenant systems we typically combine a tenant id with a bucket (date or hash) so a single tenant's load fans out across the cluster.
3. Use clustering keys to control on-disk order
Clustering columns determine the sort order within a partition and let you express range queries efficiently. Define them in the order you will query them, and pick the WITH CLUSTERING ORDER BY direction that matches your most common read (descending for time-series almost always).
4. Denormalize ruthlessly
If two access patterns need the same data sorted differently, write to two tables. Use materialized views or batch writes to keep them in sync. Worry about disk space later — query latency is what your users feel.
5. Bound your partitions for time-series
Unbounded partitions are the most common production pain we see. Bucket time-series data by hour, day, or week depending on volume so a single partition stays under the soft 100 MB / 100k row guideline. Past that, compaction, repair, and reads all start to misbehave.
Quick checklist before you ship
- Every query maps to exactly one partition (or a known small number).
- No partition is forecast to exceed 100 MB at peak retention.
- Tombstones are bounded — TTL or compaction strategy chosen deliberately.
- Read-repair, hinted handoff and incremental repair are scheduled.
- JMX and Prometheus metrics include p99 read latency by table.
Need help reviewing your schema before it hits production? GigaSpark Technologies offers a focused Cassandra data-model audit that catches partition issues, tombstone risks, and tuning opportunities before they become incidents.