1. Storage engines: B+tree vs LSM-tree

Picture a chat app whose message store takes 50k new messages per second, each keyed by channel_id plus message_id. Some messages get edited or deleted later, and most reads fetch a channel's recent history. Somewhere on each database node, a piece of software decides how those keys and values are laid out on disk and how they come back out. That piece is the storage engine.

Most relational databases use a B+tree engine that updates data in place. Write-heavy stores such as Cassandra and RocksDB use a log-structured merge tree (LSM-tree), which never overwrites a file: it buffers writes in memory and appends them to disk as sorted files, then cleans up later.

This tutorial teaches the LSM side in enough depth to walk a write, a read, a delete, and a cleanup pass, and then to choose between the two engines for a given workload. It stays on one node's disk. You should already know what a B+tree index is and that sequential disk writes are much cheaper than random ones.

The engine layer is an optional, moderate-weight topic. Many interviews never reach it, but in a key-value store, message store, or metrics prompt, "how does each node actually store this?" is a common senior follow-up worth three to eight minutes.

For a mid-level round, the right default and one reason is enough: B+tree for general read-heavy data, LSM when writes dominate. For backend and senior rounds, explain how an LSM engine's faster writes affect read latency and disk usage.