I wrote MasKV to understand what's underneath a networked database, like reading a protocol off a socket, serving several clients at once and getting the data back after a restart, all without any framework.

How it works

The server accepts TCP clients on POSIX sockets and gives each one its own thread. All clients share one in-memory store protected by a mutex. The protocol is plain text, one command per line, and supports PING, SET, GET, DEL and EXIT, with input validation and a maximum command size.

• Parser, executor, storage, networking and persistence kept in separate parts.
• Partial writes on sockets are handled, so long responses aren't cut off.
• Every SET and DEL is appended to a log that gets replayed before the server accepts connections.

Design decisions

I kept the protocol small on purpose so the project stays about systems problems. The log only records writes that succeeded, and on startup it's replayed through the same code path as normal commands, so the state is rebuilt exactly the same way.

Testing and next steps

11 unit tests cover the store, the parser and the command executor. It has some known limits. The log is never compacted, paths and ports are fixed, values can't contain spaces, and shutting down the worker threads cleanly is still to do.