You are designing the simplest thing that could possibly work as a key-value store: clients send put(k, v) and get(k); the server appends each write to a log on disk and remembers where every live record is via a hash table in memory. That's it. There is no B-tree, no LSM, no skiplist, no MVCC, no compaction strategy beyond "rewrite the live records and atomically swap pointers."

Bitcask was Riak's local storage engine and is the canonical worked example of "what does the disk actually need to do?" Every later KV store — LevelDB, RocksDB, TiKV, FoundationDB, Pebble — is "Bitcask plus an answer to one of its limits." Once you have built Bitcask, the design space of every other embedded KV store collapses to a small set of named trades.

Resist the urge to "describe Bitcask." Make decisions yourself, defend them, and let the design push back. The point is to feel why each price is paid and which workload pays it.