Distributed Key-Value Store with Raft Consensus
Implement Raft from the paper and build a replicated key-value store on top that stays consistent through node failures and network partitions. Demanding, unambiguous, and the project that most reliably demonstrates real systems ability.
Advanced
Needs a team, real planning, and a supervisor who knows the area.1 semester, 2 to 3 students
5 to ship
3 optional extrasSuggested stack
What you should ship
- Raft implementation covering leader election, log replication and safety, following the paper
- Persistent state surviving restart, since a node that forgets its vote breaks correctness
- Key-value store on top with a client library that handles leader redirection
- Snapshotting so the log does not grow without bound
- A test harness injecting partitions, node failures and message reordering, with linearizability checked
If you have time left
- Membership changes allowing nodes to join and leave a running cluster
- Read-only optimisation using leases to serve reads without a full round trip
- Sharding across several independent Raft groups
Why this project
Consensus is the hardest widely used idea in distributed systems, and implementing it correctly is the clearest possible demonstration that you understand the field. There is also no ambiguity about whether it works: it either remains consistent under partition or it does not.
What you build
Raft from the paper, persistent state, a key-value store, snapshotting, and above all a test harness that tries to break it.
The test harness is half the project
Anyone can write code that works when nothing fails. The contribution is a harness that partitions the network, kills the leader mid-append, delays and reorders messages, restarts nodes with stale logs, and then verifies that the observed history is linearizable. Report how many randomised runs pass.
The part everyone gets wrong
Persistence. Current term and voted-for must be written to durable storage before responding to a vote request. Skipping this produces a system that appears to work in testing and can elect two leaders after a restart, which is a silent correctness failure and exactly the kind of bug this project exists to teach.
Read the paper properly
The extended Raft paper is clear and complete, and its figure specifying the algorithm is the specification. Implement exactly what it says before optimising anything.
Scope warning
Single Raft group. Sharding and membership changes are stretch goals; a correct single group with a rigorous test harness is a strong project on its own.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.