CONCEPT Cited by 1 source
Read amplification¶
Read amplification is the ratio between the number of client-issued read operations and the number of substrate-level read operations they fan out into. A single user-facing read can become thousands of backend reads when:
- a request walks an index → record indirection multiple hops deep;
- a graph traversal expands across high-fanout nodes;
- a query joins many small tables;
- a tiered storage stack has multiple layers of metadata lookups (e.g. Parquet → manifest → catalog).
The dual concept is write amplification, where one client write fans out into many substrate writes (LSM compaction, multi-index updates).
In graph traversals¶
Graph traversals are the canonical worst case. Verbatim from Netflix Graph Abstraction Part I:
"A single traversal request on the fronting service may translate into thousands of fetch operations on the backend, especially for highly interconnected graphs."
A 2-hop traversal "with a higher degree of fan-out" (Netflix's Real-Time Distributed Graph is the named example) can generate hundreds to thousands of edge-link reads, plus a property fetch for each surviving link, plus per-node property reads for the endpoints — and Netflix achieves this in p90 < 50 ms because of the layered cache hierarchy and the per- namespace storage layout.
Why caching matters here¶
A storage layer alone cannot absorb 1000× read amplification at sub-second latencies — durable stores are not engineered for that point on the throughput / latency trade. Read-amplification mitigation requires:
- Layered caching — most fetches don't hit durable store (Netflix: EVCache read-aside).
- Pushdown — filter / select at the storage layer so the data crossing back is already shaped (Netflix: property-selection pushdown + property-filtering pushdown).
- Bounded fanout — operational invariant on the data shape (Netflix: per-source-node edge cap to keep latest-sort traversals tractable).
- Schema-aware path elimination — drop traversal paths the schema doesn't permit before reads issue (concepts/in-memory-schema-metadata-graph).
- Parallelisation — issue per-edge fetches concurrently, not serially.
Read vs write amplification asymmetry¶
| Aspect | Write amplification | Read amplification |
|---|---|---|
| Source | indexes, replication, LSM compaction | traversal fanout, joins, multi-tier metadata lookups |
| Cap | Bounded by index count + storage policy | Unbounded — depends on data shape and query depth |
| Mitigation | batch writes, write-aside cache for existence checks | layered caching, pushdown, query bounds, parallel fetch |
| Tooling | usually known statically | usually requires per-query profiling |
In high-fanout graph workloads the asymmetry tilts: read amplification is typically the order-of-magnitude harder problem because the fanout depends on the data, not just the schema.
Operational metric¶
Netflix tracks edge fanout at different depths as a first- class operational metric (concepts/graph-traversal-fanout). Median and max fan-out at hop depth n is the structural predictor of read amplification for n-hop traversals. The Part-I post shows charts of "median edge fan-out" and "max edge fan-out" alongside the latency distributions.
Seen in¶
- sources/2026-05-29-netflix-high-throughput-graph-abstraction-at-netflix-part-i — canonical wiki disclosure; verbatim "thousands of fetch operations on the backend" per traversal request as the motivation for the EVCache read-aside layer with dual invalidation strategies.