Ternion
A key-value database in Go that uses Raft consensus to keep three nodes consistent through crashes and network partitions.
Overview
Ternion is a systems project about keeping replicated data consistent when machines fail. I wrote the Raft state machine, storage layer, and gRPC API. A write succeeds only after a majority has saved it, and the leader checks with a fresh quorum before serving a read.
What I built
- Implemented leader election and log replication as a deterministic state machine. The cluster can keep serving requests after one node fails, as long as two nodes can communicate.
- Added typed gRPC calls for reads, writes, and deletes. Followers point clients to the leader, and session sequence numbers prevent retries from applying the same mutation twice.
- Persisted state in checksummed log segments and snapshots. A restarted follower catches up through log replication or receives a snapshot when its missing history has been compacted.
- Tested elections, partitions, and recovery in real processes and with replayable fault schedules. A Docker walkthrough kills the leader, isolates a minority, and demonstrates snapshot recovery.