EzRaft: Build a Distributed KV Store in 100 Lines

For the past few years, I have spent most of my time working on OpenRaft.

OpenRaft is an open-source project that runs in production at companies around the world. To support such a wide range of applications, it has to be highly flexible. Log entries, log IDs, state machines, and storage are all expressed as Rust traits, so users can adapt them to their own needs.

Today, OpenRaft’s API and performance are both fairly mature. The trade-off is that its model of the Raft algorithm remains quite abstract.

The OpenRaft Learning Curve

That abstraction creates a steep learning curve. There are three main parts:

1. Understanding the Raft consensus algorithm: Before you can build a distributed store on OpenRaft, you need to understand what Raft guarantees—and what it does not.
2. Understanding Rust: OpenRaft is written in Rust. Reading the code and building an application requires some familiarity with Rust’s abstractions and generics.
3. Understanding OpenRaft’s own abstractions: Abstraction makes software easier to use once you understand the model. It gives experienced users convenience and flexibility. But when you are learning the system from the bottom up, the abstraction itself becomes another thing you must first understand.

This is a common problem with abstractions: before the whole system makes sense, you must understand how all of its abstract pieces fit together. Most people learn more naturally in the other direction—from concrete examples to general ideas.

Give someone an abstraction and ask them to imagine a concrete example, and the idea can be hard to grasp. Give them a concrete example first, and the underlying pattern is much easier to see. OpenRaft’s abstractions make it a powerful, stable tool, but not necessarily an easy place to start learning.

Why I Built EzRaft

As the maintainer of OpenRaft, I regularly hear from developers who are new to distributed systems, Rust, or OpenRaft itself. They want to…