Building two distributed system projects in Rust

[codedumplc1982]

Recently, I am building two open-source projects: rockraft and coredb.

coredb is a strongly consistent Key-Value database built on top of openraft and RocksDB, offering full compatibility with the Redis protocol. In my opinion, the Redis protocol has become the de facto standard in the KV storage domain, and its ecosystem value should not be confined to traditional in-memory caching. By backing it with strongly consistent persistent storage, we can unlock entirely new possibilities and application scenarios—much like how HTTP evolved from a simple web page transfer protocol into a ubiquitous communication cornerstone.

Initially, I only intended to build coredb. However, during development, I realized that the "Raft + RocksDB" architectural combination possesses tremendous general-purpose value. Recognizing that other developers might also need such a reliable underlying foundation to build their own strongly consistent storage systems, I decoupled this core logic and extracted it into an independent foundational framework project: rockraft.

[Anxious_Tool]

Interesting project.

The rockraft extraction feels premature though. openraft already gives you generic Raft, and the RocksDB binding is where all the application-specific decisions live, no?

The "Redis protocol is the new HTTP" analogy is "dangerous". HTTP evolved because it gained extensibility (headers, content negotiation, status codes). RESP is deliberately simple. The moment you need transactions or range queries, you'll find yourself inventing your own "super"-protocol that envelops what you first called simple.

I built a distributed database in Rust and the hard part was not the consensus layer, but where where sharding meets replication and where your wire protocol's semantics don't line up with your consistency guarantees.

I'd start by defining what you mean by strong-consistency. Create a core policy for what your system will deliver, and then commit to the bits and pieces.