Read Amplification: What It Is, With Worked Examples

Read amplification is the number of bytes a storage system really reads divided by the bytes the caller asked for. Ask for 1 KB, and if the disk moves 4 KB, the read amplification is 4x.

The cause is that storage never reads exactly what you want. It reads in fixed blocks, it checks several places, and it may ask several machines.

A simple example makes it clear. A B-tree stores rows in 16 KB pages. You read one 100 byte row. The engine still loads the whole 16 KB page, so amplification is about 160x for that read.

That is not a bug. It is the price of an index that stays fast for every other access pattern.

The Three Amplifications

Storage engines trade three costs against each other. You cannot make all three small.

This is known as the RUM trade-off, for read, update and memory overheads. Lower one and at least one of the others rises.

Read Amplification in LSM Trees

Log structured merge trees are the clearest case. RocksDB, LevelDB, Cassandra and HBase all use them.

Writes go to memory first, then to a sorted file on disk. Files pile up in levels. A key may live in the memtable, or in any file at any level.

So one point lookup may check many files. With 7 levels, a lookup for a missing key can touch 7 files before it gives up.

Two things cut that cost. A bloom filter per file answers "this key is definitely not here" in memory, which removes most of the file reads. A block index inside each file points at the right 4 KB block.

Compaction also helps. Merging files reduces how many places a key can hide. The cost is write amplification, often 10x to 30x in a level based engine.

Read Amplification From Sharding and Replicas

Amplification is not only a disk effect. It also appears when one query fans out.

A search query sent to 20 shards causes 20 reads, even though the user wanted one result list. The coordinator then merges the results.

Redundancy adds to this. If a record is copied into several shards so that any shard can answer, the same record gets read more than once across the fan-out. Read amplification from shard redundancy is a real design cost, not a mistake in configuration.

The fix is not to remove redundancy. It is to route the query. Send it only to shards that can hold the key, using the partition key or a routing field.

Why It Matters

High read amplification shows up as three problems.

Latency rises, because more blocks must be fetched. Throughput falls, because the disk and network do more work per request. Cost rises, since you buy more IOPS and more cache to hide the same load.

Put a number on it. A disk that serves 50,000 reads per second supports 50,000 user reads at 1x. At 8x it supports about 6,250.

How to Reduce It

• Cache hot data in memory, which removes the disk read entirely for repeat reads.
• Add bloom filters so a lookup skips files that cannot hold the key.
• Match the page or block size to your typical row size.
• Use a covering index, so the answer comes from the index and no row fetch is needed.
• Compact more often, which lowers reads and raises writes.
• Route queries to one shard instead of all of them.

Caching has a limit worth stating. It does nothing for cold reads or for a scan over data you touch once.

Separating traffic also helps. With read and write separation, heavy reads move to replicas and stop competing with compaction on the primary.

How to Prepare

• Lead with the ratio. Say it is bytes read divided by bytes requested, then give the 1 KB and 4 KB example.
• Name the trade-off. Mention write and space amplification in the same answer, because that shows you know the engine.
• Know one LSM detail. Bloom filters and level count are the two facts that carry the point.
• Learn the cache patterns. Compare read-through and write-through caching and know when each helps.
• Connect it to replication. See how database replication spreads read load.
• Study the storage chapter properly. Grokking System Design Fundamentals covers indexing, caching and sharding together.