Before a scale-up or a migration, a Cassandra cluster is judged on p99 latency and the health of its data model. As an independent Cassandra consultant I work on data modeling, repairs, compactions and multi-datacenter design, with Cassandra and ScyllaDB in production. Proof point: Cassandra performance and reliability at BPCE-IT for an API Management platform. Full references under NDA.
Audit and tuning
The data model first: partitions too wide or too narrow, badly distributed partition keys, tables accumulating tombstones. Then execution: a compaction strategy matched to the read profile, garbage collector configuration, read consistency at the level you need without paying for a quorum you do not. Every suspect is confirmed by trace and metric, never by intuition.
Scale and multi-datacenter
Adding nodes without a painful rebalance requires a clean topology design: NetworkTopologyStrategy per datacenter, replication factors per workload, clients placed close to their replicas. The growth plan covers node additions, the repair capacity that comes with them, and the datacenter-loss scenario, documented and tested rather than assumed.
Benchmark
The measurement covers p99 latency and sustained throughput, not a flattering average: cassandra-stress or nosqlbench configured on your real workload profile, mixed read and write, reproduced application concurrency. A Cassandra benchmark that does not report the tail of the distribution says nothing about what your users will experience.
This is not staff augmentation or development work: for a single technical decision, the flash review is enough.
FAQ
Why does Cassandra latency degrade in spikes rather than on average?
Because most reads are served by healthy replicas, and the tail of the distribution depends on the rare cases: late repairs, compactions running, wide partitions, tombstones to filter. The average stays green while p99 degrades the experience. Cassandra tuning is precisely about attacking that tail, not the average.
How do I know if my Cassandra data model is healthy?
A healthy model places the partition key along the main query, keeps partitions within a size that reads without excessive latency, and limits collections that generate tombstones. The audit checks those three points table by table against real metrics, then proposes schema migrations that fix without downtime.
Should I add nodes or fix the data model?
Adding nodes solves a capacity deficit, not a modeling defect: badly designed partitions stay slow on a bigger cluster, and the bill follows. The right order is to fix the model and configuration first, then size the cluster that remains necessary, often smaller than expected.