If you simply want to have an implementation of KeyValueStoreMemory that doesn’t use the disk, then I think I agree with Markus that it wouldn’t be too hard to do. If you want your cluster to use no disk at all, however, you’ll have some other files to deal with as well.
I believe for the memory storage engine, the KeyValueStoreMemory is used by the data files on the storage server, the persistent data store on the transaction logs, and the coordinators. I haven’t really considered whether there are any issues (besides lack of durability and upgradability) that could arise from not using the disk in each of these situations.
In addition to the above files, there are trace logs, a cluster file, and a processId file for each process. For the transaction logs, there is also another DiskQueue that is not associated with a KeyValueStoreMemory. Depending on how strict your requirements to not use the disk are, you may be ok to have some of these files on disk given that they don’t get used much. The transaction log’s DiskQueue is very frequently written and synced, however, so using it may not meet your requirements. It’s possible that a similar approach to what Markus suggested could work here (i.e. don’t use the DiskQueue or give it an implementation that does nothing), but I again haven’t given it much thought.
There are also problem a few scattered places that interact with the disk in various ways (for example, to collect metrics). It wouldn’t surprise me if some of those would require changes to work too.