You are designing the storage engine that gave us BigTable, Cassandra, HBase, LevelDB, RocksDB, Pebble, TiKV, and FoundationDB-on-RocksDB. The brief is brutal in its specificity:

• you want ordered reads (range scans by key, prefix iteration);
• you want more keys than fit in RAM (so the index cannot live there);
• you want fast writes under high cardinality and random key order (so you cannot pay a seek per write).

The previous curriculum (Bitcask) gave you O(1) point reads and append-only writes — and could not do range scans, and OOM'd on high cardinality. The other obvious answer (a B-tree on disk) does range scans fine, and pays one seek per random-key insert, which on a single SSD pegs at hundreds of writes per second. Neither fits the brief.

LSM is the design that takes both blockers off the table. You do not avoid the trade — you reshape it. Writes go to RAM at memory speed; an append-only log on disk survives the crash; sorted files on disk get binary-searched; a tiny bitmap per file says "definitely not here"; a background process merges sorted files forever. Eleven scenes; eleven structural choices; one design space that contains every modern KV store you will meet.

Resist the urge to "describe an LSM." Build it from first principles, defend each step, and let the workload push back. The point is to feel why each cost is paid and which workload pays it.