Stage 1: The Memtable

Objective:Implement the in-memory foundation that every LSM engine builds on top of.

Every LSM-tree engine starts with a memtable -- an in-memory map that absorbs all writes at RAM speed. Reads check it first; deletes are just another kind of write.

Implement createStore() returning an object with:

• set(key, value) -- store a value
• get(key) -- return the value, or undefined if absent
• del(key) -- remove the key
• has(key) -- boolean

Sounds trivial -- it is, deliberately. Real engines are layers on exactly this core, and every later stage builds on yours. Get the semantics right: overwrites replace, deleted keys read as undefined, and has reflects deletes.

Why this is the right abstraction: RocksDB's MemTable is backed by a concurrent skip list. Cassandra uses a ConcurrentSkipListMap. You're using a JavaScript Map -- the data structure is different, the interface is identical. You're building the interface, not the skip list.

Why this matters in production

Every serious write-heavy database (RocksDB, Cassandra, LevelDB) starts here. The memtable is the reason LSM engines can absorb millions of writes per second -- all mutations land in RAM first, then get flushed to disk in sorted batches. Getting the semantics right (overwrites replace, deleted keys are invisible) is a prerequisite for every stage after this; Stage 3 will flush this structure to disk and Stage 4 will merge multiple copies of it.