Systems & CLI · Advanced
Distributed Key-Value Store With Raft
Implement Raft leader election and log replication from scratch, build a replicated key-value store on top, add snapshots and membership changes, and survive partitions under a fault injector.
You build a fully replicated key-value store backed by your own Raft implementation, covering leader election, log replication, log compaction via snapshots, and dynamic cluster membership. The project forces you to reason precisely about distributed systems correctness: every invariant in the Raft paper becomes a bug if you ignore it. Running a Jepsen-style partition fault injector against your cluster and watching it pass is the benchmark that proves the implementation works.
What you build
- Raft leader election with randomized election timeouts and vote deduplication
- Log replication with AppendEntries RPCs, commit index tracking, and follower catch-up
- Linearizable GET and PUT operations exposed over a gRPC API
- Log compaction with InstallSnapshot so new nodes bootstrap from a snapshot rather than replaying the full log
- Dynamic cluster membership changes using joint-consensus or single-server transitions
- Persistent state (currentTerm, votedFor, log) on disk via BoltDB so nodes survive crashes and restarts
- Automated fault-injection tests that verify correctness under leader kills, network partitions, and message delays
What it teaches
- Raft consensus mechanics: elections, log matching property, and the commit rule
- Distributed systems safety vs. liveness tradeoffs and why quorums matter
- gRPC service design for low-latency RPC-heavy workloads
- Crash recovery and durable state management with embedded databases like BoltDB
- Snapshot and log compaction strategies to bound disk and memory usage
- Fault injection and linearizability checking as a correctness verification technique
How it works
- 1
Client
- Issues PUT key=val via gRPC to any node
- 2
Leader
- Appends entry to local log
- Broadcasts AppendEntries to followers
- 3
Followers (2 of 2)
- Append entry to local log
- Reply success to leader
- 4
Commit
- Leader advances commitIndex once quorum acks
- Applies entry to state machine (KV map / BoltDB)
- 5
Response
- Leader returns OK to client
- Followers learn commitIndex on next heartbeat
Sign in to open the build guide
Free account. Get the step-by-step build and every resource link.
Take it further
- Implement multi-key transactions using a two-phase-commit layer on top of the replicated log.
- Add a read-index or lease-based optimization so follower reads are served locally without going through the leader.
- Port your fault-injection suite to use the Jepsen framework and publish the results as a correctness report.
