Read Amplification Tax

Read latency on a write-heavy LSM-based node has crept up, and metrics show hundreds of SSTables accumulated for the affected key range while write throughput is unchanged. What is happening and what fixes it?

The read quorum is too large, so dropping R to 1 removes the extra replica round trips that now dominate the read latency

A point lookup may consult many SSTables, so Bloom filters skip files that cannot hold the key and compaction bounds the count

Reads return stale data because compaction has not yet propagated the newest write, so the memtable should be flushed more often

The node is short of replicas for that range, so raising the replication factor spreads reads and cuts the per-read work