hashicorp/raft

★ 9,010GoAudience · developerComplexity · 4/5Setup · hard

Mindmap

mindmap
  root((repo))
    What it does
      Leader election
      Log replication
      Snapshot support
    Tech stack
      Go
      BoltDB
      LMDB
    Use cases
      Distributed systems
      Key-value stores
      Fault tolerance
    Audience
      Go developers
      Systems engineers

mindmap root((repo)) What it does Leader election Log replication Snapshot support Tech stack Go BoltDB LMDB Use cases Distributed systems Key-value stores Fault tolerance Audience Go developers Systems engineers

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Build a distributed key-value store in Go that stays consistent across multiple servers even when some go offline.

USE CASE 2

Add leader election and replicated logging to a cluster of servers so they agree on shared state automatically.

USE CASE 3

Integrate the library with gRPC to build a fault-tolerant distributed service in Go using BoltDB for log storage.

Tech stack

GoBoltDBLMDBgRPC

Getting it running

Difficulty · hard Time to first run · 1day+

Requires implementing a custom state machine interface and setting up a multi-node cluster, no built-in database layer.

In plain English

This is a Go library from HashiCorp that implements the Raft consensus protocol. Consensus, in computing, means getting a group of servers to agree on a shared record of events, even when some servers fail or go offline. This library is the building block that powers HashiCorp's own products like Consul, and it is used broadly in distributed systems where multiple machines need to stay in sync. The way it works: a group of servers (called a cluster) elects one leader. All writes go to the leader, which records each change and sends copies to the other servers (followers). Once enough followers confirm they received the entry, the change is considered committed and takes effect. If the leader disappears, the remaining servers hold an election and pick a new one. A cluster of three servers can survive one failure, five servers can survive two. The library manages its own log storage, periodically compresses old history into snapshots so disk space does not grow forever, and handles servers joining or leaving the cluster. It does not dictate what your application does with those committed entries, instead, it calls into a state machine interface that you implement, so the actual business logic stays in your code. For storage backends, the library ships without a built-in database layer. HashiCorp maintains two separate companion libraries: one based on BoltDB (pure Go, no C dependencies) and one based on LMDB, which is the recommended choice for production. Community examples on GitHub show how to pair the library with gRPC or build a distributed key-value store on top of it. This is a lower-level building block aimed at developers writing distributed systems in Go, not an end-user application. If you need servers to agree on shared state reliably, this library provides the coordination mechanism.

Copy-paste prompts

Prompt 1

Write a minimal Go example using hashicorp/raft that starts a 3-node cluster on localhost, elects a leader, and commits a log entry.

Prompt 2

Show me how to implement the FSM interface in hashicorp/raft to build a distributed key-value store that applies committed entries.

Prompt 3

How do I add a new node to a running hashicorp/raft cluster using raft.AddVoter and handle the configuration change safely?

Prompt 4

Help me set up snapshot support in hashicorp/raft with BoltDB so disk usage does not grow unbounded over time.

Open on GitHub → Explain another repo

← hashicorp on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.