Explain the read path in Cassandra?

Reads are more involved than writes because data for one partition can be spread across the memtable and several SSTables.

flowchart LR
A[Client read request] --> B[Coordinator node]
B --> C1[Replica 1]
B --> C2[Replica 2 - if CL requires]
C1 --> D[Check Memtable]
C1 --> E[Bloom Filter per SSTable]
E -->|maybe present| F[Partition Key Cache / Index]
F --> G[Read relevant SSTable blocks]
D --> H[Merge results by timestamp]
G --> H
H --> I[Return most recent value to coordinator]

1. The coordinator determines which replicas hold the partition and sends the request to enough of them to satisfy the consistency level.
2. Each replica checks its memtable, then uses a Bloom filter per SSTable to quickly skip files that definitely do not contain the partition.
3. For SSTables that might contain the data, the partition index (and key cache, if enabled) locates the exact block on disk.
4. Results from the memtable and all relevant SSTables are merged, keeping only the most recent value per column based on timestamps.
5. If configured, a background read repair reconciles any replicas that returned stale data.

This is why wide partitions with many SSTables can slow reads down: more files means more Bloom filter checks and more merging work per query.