100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace

What is Write Amplification and Why Does It Matter for Storage Engines?

Learn what write amplification is, how LSM compaction and SSD garbage collection cause it, and how to reduce its impact.

hardQ169 of 224 in System Design Est. time: 6 minsLast updated:
Open Code Lab

Expected Interview Answer

Write amplification is the phenomenon where a single logical write from an application triggers a much larger amount of physical data actually written to durable storage, because the storage engine has to rewrite, compact, or relocate existing data as a side effect of that one write.

In log-structured merge-tree (LSM) engines like RocksDB or Cassandra’s SSTables, a single key update first lands in an in-memory memtable and a write-ahead log, but later gets flushed to disk and then repeatedly rewritten during compaction as it merges across levels to keep read performance and space usage bounded — so one logical write can be physically rewritten many times over its lifetime. On flash-based SSDs, write amplification also happens at the hardware level: because flash can only be erased in large blocks but written in smaller pages, updating a few pages inside an already-used block forces the SSD’s garbage collector to copy the still-valid pages elsewhere before erasing and reclaiming the block, multiplying physical writes beyond what the host actually requested. High write amplification matters because it directly consumes I/O bandwidth that could serve other requests, accelerates flash wear (each physical cell has a finite erase-cycle lifetime), and increases tail latency when compaction or garbage collection bursts compete with foreground traffic. Engineers manage it by tuning compaction strategy (size-tiered trades more write amplification for less read/space amplification; leveled trades the reverse), over-provisioning SSD capacity, and choosing engines matched to the workload’s write/read ratio.

  • Understanding it explains real I/O and cost overhead beyond the logical write size
  • Guides compaction strategy choice (size-tiered vs leveled) to fit read/write/space priorities
  • Explains SSD wear and informs over-provisioning and hardware lifetime planning
  • Helps diagnose tail-latency spikes caused by background compaction/GC competing with foreground I/O

AI Mentor Explanation

Write amplification is like a groundskeeper who, to update one line on the scoreboard, has to physically repaint several older sections that were sharing the same panel because paint cannot be applied to just one line cleanly. What looks like a single scoring update to the crowd actually costs the groundskeeper several extra strokes of paint across the panel. Over a long match with constant updates, this repeated repainting adds up to far more work than the number of actual score changes. That gap between the one logical update and the much larger physical repainting is exactly write amplification.

Step-by-Step Explanation

  1. Step 1

    Logical write arrives

    The application issues one small write (e.g., a key update) to the storage engine.

  2. Step 2

    Write lands in a mutable buffer

    It is appended to a write-ahead log and an in-memory structure (e.g., memtable) for durability and speed.

  3. Step 3

    Buffer is flushed to disk

    When full, the buffer is flushed as an immutable file (e.g., SSTable), the first physical write of that logical update.

  4. Step 4

    Compaction/GC rewrites it again

    Background compaction (LSM) or garbage collection (SSD flash) later rewrites/relocates that data multiple more times, amplifying total physical I/O.

What Interviewer Expects

  • Defines write amplification as the ratio of physical bytes written to logical bytes requested
  • Names concrete sources: LSM compaction and SSD flash garbage collection
  • Discusses the compaction strategy trade-off (size-tiered vs leveled)
  • Connects high write amplification to I/O bandwidth cost, SSD wear, and tail latency

Common Mistakes

  • Confusing write amplification with simple replication overhead
  • Not naming a concrete cause (compaction, flash GC) when asked to explain it
  • Assuming write amplification only matters for SSD hardware, ignoring LSM engine-level causes
  • Not mentioning any mitigation (leveled compaction, over-provisioning, tuning flush size)

Best Answer (HR Friendly)

Write amplification is when one small update you make ends up causing the storage system to physically rewrite a lot more data than that single change, because of how storage engines organize and clean up data in the background. It matters because it uses up extra I/O capacity, wears out flash storage faster, and can cause slow response times when that background work spikes.

Code Example

Compaction strategy trade-off (illustrative config)
storageEngine: lsm

compaction:
  strategy: leveled       # or “sizeTiered”
  # leveled: lower write amplification per level is NOT true - leveled
  # actually has HIGHER write amplification but LOWER read/space amplification
  levels:
    - { level: 0, maxSizeMB: 64 }
    - { level: 1, maxSizeMB: 640 }
    - { level: 2, maxSizeMB: 6400 }

ssdTuning:
  overProvisioningPercent: 20   # spare flash blocks reduce GC-driven amplification
  trimEnabled: true             # lets the SSD reclaim deleted blocks proactively

metrics:
  writeAmplificationFactor: physicalBytesWritten / logicalBytesRequested

Follow-up Questions

  • How does leveled compaction trade more write amplification for less read and space amplification compared to size-tiered?
  • Why does over-provisioning an SSD reduce write amplification from garbage collection?
  • How would you measure write amplification factor in a production LSM-based database?
  • What is the relationship between write amplification and flash cell wear-out (P/E cycles)?

MCQ Practice

1. How is write amplification factor typically defined?

Write amplification factor measures how much extra physical I/O a storage engine performs per logical write.

2. What is a primary cause of write amplification in LSM-tree storage engines?

Compaction merges and rewrites SSTables across levels to bound read cost and reclaim space, physically rewriting data multiple times.

3. Why does updating a few pages in a used SSD flash block cause write amplification at the hardware level?

Flash erase granularity is coarser than write granularity, forcing the garbage collector to relocate still-valid pages before reclaiming a block.

Flash Cards

What is write amplification?When one logical write causes a much larger amount of physical data to actually be written to storage.

Name two sources of write amplification.LSM-tree compaction rewriting data across levels, and SSD flash garbage collection relocating valid pages.

Size-tiered vs leveled compaction trade-off?Size-tiered has lower write amplification but higher read/space amplification; leveled is the reverse.

Why does write amplification matter?It consumes extra I/O bandwidth, accelerates SSD wear, and can cause tail-latency spikes from background rewrites.

1 / 4

Continue Learning