cassandra_client_request_read_time_50p

When pending compaction tasks accumulate faster than they can complete, reads must scan excessive SSTables, driving p99 latency upward and eventually causing timeout exceptions. This silent storage debt compounds over time.

Frequent deletes create tombstones that must be scanned during reads. When tombstone counts exceed 1000 per read, query latency degrades dramatically despite healthy system resources, often masking as a generic slow query problem.

When Cassandra's internal thread pools (read, mutation, request, compaction) become saturated with blocked tasks, new requests queue up or fail despite available system CPU. This creates latency spikes before visible service degradation.

When cassandra_key_cache_hit_rate drops significantly below historical baseline, reads bypass cache and hit disk directly, multiplying I/O load and latency. This often correlates with workload changes or cache size misconfiguration.

Low cassandra_key_cache_hit_rate forces Cassandra to read row locations from disk on every query instead of memory, multiplying disk IO. Degraded cache performance appears as read latency increases without corresponding write load changes.