Explain the internal working of ScyllaDB's read path?

A read has to reconstruct the current value of a row from potentially several places at once, since data for one partition can be spread across the memtable and multiple SSTables.

Each replica first checks its memtable (freshest data) and row cache (hot data already assembled), then uses per-SSTable bloom filters to cheaply skip SSTables that provably don't contain the requested key, and consults the index of the remaining candidates to locate the row's position on disk. All the fragments found are merged, respecting write timestamps and tombstones, into a single up-to-date view of the row. If the read's consistency level requires multiple replicas to respond, the coordinator compares their answers and, if they disagree, can trigger a foreground read repair to reconcile the difference before returning the final result to the client - which is one way ScyllaDB heals minor replica drift opportunistically, on top of scheduled anti-entropy repair.