When a system design discussion reaches the storage layer of a write-heavy service, saying "use an LSM tree" is a good start. The follow-up interviewers like is: how does compaction work, and what does it cost?
Writes go to an in-memory memtable, which is flushed as an immutable sorted file (SSTable). Over time you accumulate many SSTables with overlapping keys, old versions and tombstones. Reads would have to check them all, and disk usage grows. Compaction merges SSTables, keeps the newest version of each key and drops deleted data.
Compaction strategies trade these against each other; you can't minimize all three.
Group SSTables of similar size and merge them when a tier has enough files (for example four). Writes are cheap because data is rewritten only a few times. But a key may live in many tiers, so reads touch more files, and a big merge temporarily needs extra free space, sometimes close to double. Good fit: write-heavy, append-like workloads (Cassandra's default for a long time).
Organize SSTables into levels where each level is about 10x larger than the one above, and within a level (below L0) key ranges don't overlap. A read checks at most one file per level, and space overhead stays around 10%. The cost is higher write amplification, since data gets rewritten as it moves down levels. Good fit: read-heavy or update-heavy workloads (RocksDB and LevelDB default).
One-line answer: "Size-tiered favors write throughput, leveled favors read latency and disk space; I'd choose based on the read/write ratio and whether data is updated in place."
Disclosure: I work on Linkjob.ai, an AI copilot for technical interviews. This is general study material.