📄️ Architecture overview
QuorumKit has two public APIs and a shared implementation underneath.
📄️ Repository layout
The directory tree is organized so you can tell at a glance whether something is a public contract or an internal detail.
📄️ Canonical public API
The QuorumKit API lives under include/quorumkit/. It is the surface new applications should build against.
📄️ braft compatibility surface
The headers under include/braft/ exist so that code already written against braft keeps compiling.
📄️ Internal architecture
Everything under src/internal/ is implementation. None of it is installed as public headers. It can change between releases without notice.
📄️ Runtime and execution model
The Raft core in QuorumKit is a state machine. It takes inputs (messages from peers, timer expirations, client requests) and produces outputs (messages to send, log entries to write, state transitions to apply). It does not own a thread, read a clock, or generate random numbers by itself.
📄️ Transport layer
The Raft core never opens a socket. It produces protocol messages (RequestVote, AppendEntries, InstallSnapshot) and hands them to a transport adapter, which decides how they actually get delivered.
📄️ Storage layer
The Raft core needs three kinds of persistent state: the log (the ordered sequence of entries), metadata (current term, voted-for), and snapshots (compressed checkpoints of the state machine).
📄️ Testing architecture
Current state
📄️ Build and packaging modularity
The source tree defines what is public, what is internal, and where optional pieces plug in. The build system follows that structure -- it does not impose its own.
📄️ Protocols and features
Not everything in QuorumKit is Raft consensus. The library has a small core protocol and a larger set of features built around it.
📄️ Compatibility and migration
QuorumKit needs to keep existing braft deployments working while moving the API and internals forward. That means two kinds of compatibility: API compatibility and storage compatibility.