Definition
A log-structured merge tree is a storage structure that turns random writes into sequential ones. Incoming writes go to an in-memory sorted table (the memtable) plus a write-ahead log for durability; when the memtable fills, it is flushed to disk as an immutable sorted file (an SSTable). Background compaction merges those files, discarding overwritten and deleted keys.
The consequence is a write path that is close to sequential and therefore very fast, at the cost of a read path that may need to check several files before finding a key — which is why LSM engines lean on Bloom filters and per-file key ranges to skip files quickly. This is the opposite trade from a B-tree, which updates pages in place: B-trees give lower read amplification, LSM trees give lower write amplification. RocksDB, Cassandra, and the storage layers of many modern key-value stores are LSM-based for exactly this reason.
How it comes up in interviews
The question is usually framed as "why not just use a B-tree?" and the expected answer is a workload argument: write-heavy ingest favors LSM, read-heavy point lookups favor B-trees. Mentioning compaction as an ongoing background cost — and the write stalls it can cause under sustained load — shows you know the failure mode, not just the diagram.