How it works
Start by defining the measurement boundary. Storage-engine write amplification is bytes written by the engine divided by logical bytes written by the application over the same workload interval. For example, 10 GB of logical updates causing 60 GB of engine writes means 6× write amplification.
An LSM-tree typically records a write in a write-ahead log and buffers it in memory. It later flushes sorted files to disk, then compacts files to merge updates and discard obsolete versions. Compaction rewrites surviving data, including records that the application has not recently changed.
B-trees have different sources of extra work. A small row update may dirty a much larger page, require logging, and occasionally cause page splits. Buffering can combine changes before a page is written, so neither B-trees nor LSM-trees have a fixed amplification factor.
Indexes and derived views add writes above the storage-engine layer. Changing an indexed field can require removing its old index entry and inserting a new one. At the application layer, fan-out on write might turn one post into 1,000 recipient-feed entries; that is operation amplification, not automatically 1,000× byte amplification.
Replication multiplies writes across nodes, and an SSD can perform additional internal writes for garbage collection. Keep these boundaries separate: an engine-only factor excludes replica copies and SSD-internal work unless explicitly stated. Measure over a representative interval that includes background work, rather than just a short burst before compaction catches up.
A worked example
Sizing a write-heavy metrics store
Suppose a metrics service accepts 100,000 samples per second, each represented by 100 logical bytes. That is 10 MB/s of logical ingestion. For this hypothetical workload, a sustained test measures 6× engine write amplification, including the WAL, flushes, and compaction but excluding replication and SSD-internal writes. Each full replica therefore needs about 60 MB/s of sustained device-facing write bandwidth. With three replicas, aggregate writes are about 180 MB/s. This is a baseline, not a safe provisioning target: recovery, bursts, and uneven partitions need headroom. If the design adds a separately stored index, estimate its logical writes and engine cost separately unless the measurement already includes it. Validate capacity while compaction runs, not only during an initial ingest burst.
Trade-offs to say out loud
- Faster reads versus more write work
- Secondary indexes, materialized views, and precomputed feeds reduce read work but must be maintained when source data changes.
- Compaction policy
- Leveled compaction generally reduces overlapping files and space amplification, while tiered approaches often reduce rewriting at the cost of more read and space amplification.
- Batching versus freshness
- Batching and coalescing repeated updates can reduce writes, but they delay visibility and need an explicit durability policy for buffered changes.
- Durability and availability cost
- Logs and replicas consume write bandwidth but provide recovery and fault tolerance, so removing them changes guarantees rather than offering a free optimization.
- Background work versus foreground latency
- Compaction competes with requests for disk bandwidth and CPU, and an accumulating backlog can eventually force write stalls.
- Device cost and endurance
- Extra physical writes consume SSD endurance and provisioned throughput, making logical data volume alone an incomplete cost estimate.
When to reach for it
- You are sizing a write-heavy key-value store, metrics pipeline, or trace store and need to translate logical ingestion into disk bandwidth.
- The design adds secondary indexes, search indexes, rollups, or materialized views to make reads cheaper.
- You are choosing fan-out on write for a feed and need to explain how audience size changes the write workload.
- An interviewer asks why write latency spikes even though incoming request volume has not increased.
- You are comparing storage engines or compaction policies under frequent updates, deletions, and retention.
How to bring it up in the interview
- State the unit and scope first: bytes per logical byte for storage, or derived operations per application operation for fan-out; interviewers may challenge a multiplier that mixes the two.
- Estimate logical bytes per second, then account for indexes, engine rewriting, and replicas without double counting; reserve bandwidth for recovery and bursts.
- Tie each index or precomputed view to a specific read requirement, and be ready to defend its maintenance cost under updates and deletes.
- Explain what happens when background work falls behind: monitor compaction backlog, disk bandwidth, write stalls, and tail latency, then discuss throttling or backpressure.
- Propose targeted reductions such as fewer indexes, update coalescing, time-based retention, or hybrid feed fan-out, and state the freshness or query cost each introduces.
Common mistakes
- Treating one API request as one disk write and sizing storage from request count alone.
- Quoting a universal amplification factor without specifying the engine, workload, compaction policy, and measurement boundary.
- Assuming asynchronous processing or a queue removes write work rather than moving it off the request path.
- Counting replica writes twice when a measured amplification factor already includes the whole cluster.
- Ignoring deletes and retention: tombstones and obsolete versions may require later compaction, while dropping whole time partitions can avoid much of that cleanup.
Where it comes up
Interview questions where write amplification is part of a strong answer, and why.
- Design a distributed key-value storeStorage-engine rewriting and replication determine sustainable write throughput and how much capacity remains for repair and recovery.
- Design a metrics monitoring system like DatadogHigh-volume sample ingestion, rollup maintenance, and retention make physical write cost central to storage sizing.
- Design a news feed like FacebookFan-out on write turns a single post into many feed updates, motivating a hybrid strategy for large audiences.
- Design InstagramPrecomputing home feeds creates audience-dependent write work that must be bounded for very large publishers.
- Design Facebook post searchPost updates expand into inverted-index changes and segment merges, making indexing throughput and freshness dependent on write cost.
- Design a distributed tracing systemPersisting high-volume spans alongside searchable attribute indexes requires balancing query usefulness against amplified ingestion writes.
Questions people ask
How do you calculate write amplification?
Divide bytes written at a defined layer by logical bytes submitted by the application over a representative workload interval. If 20 GB of logical writes produces 100 GB of storage-engine writes, engine write amplification is 5×. Specify whether logs, indexes, replicas, and device-internal writes are included.
Why do LSM-trees have write amplification?
An LSM-tree writes data to a log and sorted files, then rewrites surviving records during compaction. The amount of rewriting depends on compaction policy, data size, update patterns, and available resources. LSM-trees trade this background work for buffered writes and efficient sequential I/O.
How can you reduce write amplification?
Remove unnecessary indexes and derived copies, coalesce repeated updates where semantics allow, and choose a compaction policy suited to the workload. Time-partitioned retention can let you drop expired files instead of deleting records individually. Each change should be checked against read latency, freshness, space use, and durability requirements.