Read-Heavy vs Write-Heavy Workload Lab (Interactive)
Slide the read:write ratio and index count to see random-overwrite thrash versus sequential-append ingestion choose your engine. Compare point-read latency, per-node write capacity, compaction stalls, and Kafka buffering across B+ Tree and LSM-tree storage engines.
B+ Tree vs LSM Tree Workload Matcher
Set the read:write ratio and watch random-overwrite physics punish the wrong engine.
How It Works Under the Hood
The read:write ratio decides your storage engine physics. B+ Trees (PostgreSQL, InnoDB) keep data in sorted 16 KB pages for 3-4 level O(log N) point reads, but every write is a random in-place page overwrite plus WAL fsync — and each secondary index adds another page to rewrite. LSM Trees (Cassandra, RocksDB) append to a MemTable and flush immutable SSTables sequentially at disk line rate, buying 10-50x write throughput at the cost of multi-SSTable reads mitigated by Bloom filters and background compaction that can stall writes.
Core Architectural Principles
- Each secondary index multiplies write amplification because it is a separate tree updated synchronously per insert.
- Fan-out-on-write pre-computes feeds at write time for O(1) reads; fan-out-on-read merges at query time.
- Time-partitioned LSM tables make deletes instant DROP PARTITION metadata operations instead of locked DELETEs.
Declare the ratio in the first three minutes and let it pick the engine: "95% writes, so an LSM store like ScyllaDB with a Kafka commit-log buffer in front." Mention CQRS denormalized read views for the read path and partition-drop retention for deletes — interviewers hear senior judgment in exactly that ordering.
B+ Trees give the fastest indexed reads and trivial transactions but crumble under high-velocity random writes; LSM trees maximize ingestion and SSD life but pay with compaction I/O spikes and read-time merge costs.