The question I want to explore
What does it take to make a key-value write survive a crash? I’m interested in the boundary between accepting a write and making it durable, especially when a process stops halfway through a file operation.
Design direction
I’d start with one writer, a write-ahead log, an ordered in-memory table, and immutable sorted files. Recovery would replay valid log records, while a manifest would identify the files that form the current database.
The design needs to distinguish a torn final append from corruption in committed history. Deletes also need a durable representation so compaction cannot bring an older value back.
Experiments I’d use
I’d compare the store with a simple reference map for normal operations, then inject failures around log synchronization, flushes, and manifest updates. For performance, I’d hold key/value sizes and durability policy constant while comparing sequential and random access.
The interesting tradeoff is how a small, understandable recovery protocol shapes the rest of the storage engine.