Distributed Systems · Implemented and tested
QuorumKV
A TCP key-value store with Raft implemented from scratch, including the persistence and client semantics needed after leader election.
Why I built it
Leader election gave QuorumKV a coordinator. It did not yet give clients safe reads, retry behavior, compacted state, or a way to change membership. I built the surrounding pieces to understand where useful consensus actually lives.
Architecture
Nodes persist term, vote, log, commit metadata, snapshots, and state-machine data in explicit checksummed formats. A TCP transport carries Raft, client, and administrative protocols. Replication workers use bounded batching and backpressure rather than allowing queues to grow without limit.
Go · Raft · TCP · WAL · ReadIndex · snapshots
Where Raft got harder
GET uses ReadIndex to confirm current-term quorum authority before returning state, preventing an isolated former leader from serving a stale value. PUT and DELETE replicate client request identity so a response lost across failover can be retried without applying the command twice. Chunked InstallSnapshot catches up followers that have fallen behind compacted log history. Joint consensus requires old and new majorities during membership transitions.
What I actually tested
- leader process kill and replacement through real node processes
- committed data and request identity surviving restart
- crashes at meaningful persistence points
- snapshot installation and post-snapshot catch-up
- joint-consensus membership changes and leadership transfer
Boundary and trade-off
The correctness properties are implemented and tested, not formally proven. Snapshot creation is manually triggered, and the project intentionally omits broad production operations and lease-based reads.