Stage 2: The Write-Ahead Log

Objective:Add durability to the memtable by logging every mutation before applying it.

RAM dies with the process. Before a real engine touches the memtable, it appends the operation to a write-ahead log (WAL) -- an append-only record that survives crashes. On restart, replaying the log rebuilds the memtable exactly. This is the durability contract of every serious database.

Extend your store: createStore(existingLog) where:

• every set appends { op: "set", key, value } to a store.log array, every del appends { op: "del", key }
• store.log is the array itself (the harness inspects it)
• when createStore(existingLog) receives a previous run's log, it replays it so the rebuilt store answers gets identically

The crash test below is literal: it builds a store, "crashes" it (discards the object), and hands your constructor the old log. Your engine either remembers or it doesn't.

The WAL in production: Postgres calls this "WAL segments." Cassandra calls it "CommitLog." Kafka calls the WAL the "log" itself (Kafka IS a WAL used as a message queue). In all cases, the file is fsynced before the operation is acknowledged to the caller -- in this track, store.log models the durable file; the array push models the fsync.

Why this matters in production

RAM is volatile -- every write in Stage 1 dies with the process. The WAL is the durability contract of every serious database: append the operation to disk BEFORE mutating RAM, then on restart replay the log to reconstruct RAM exactly. This is how Postgres WAL works, how MySQL binlog works, how Cassandra CommitLog works, and how Kafka topics work. The pattern is universal because it has a key property: an append to a sequential file is the fastest possible durable write (no seeking, no in-place update). Stage 2 makes your engine survive crashes.