Paxos vs Raft: Key Differences for Distributed Systems and CI

While improving Docker caching for Monk CI, the question led us deeper into distributed systems—and eventually to Paxos vs Raft, two of the best-known consensus algorithms used to help distributed systems reach agreement.

Both solve the same fundamental problem: helping distributed nodes coordinate despite crashes, network delays, unavailable machines, and other failures.

So what actually makes them different?

The distinction is less about their guarantees and more about how they structure the problem.

Paxos: Agree on a Value

At a high level, Paxos focuses on getting a majority of nodes to agree on a value.

Prepare
   ↓
Promise
   ↓
Accept
   ↓
Majority
   ↓
Value Chosen

A proposer sends a numbered proposal to a group of acceptors. The acceptors respond with promises about which proposals they will consider and may share information about values they have already accepted. If the proposal receives acceptance from a majority, the value is chosen.

The key idea is the quorum.

In a five-node cluster, for example, three nodes form a majority. Because majorities overlap, the system can preserve agreement even if some nodes fail or become temporarily unreachable.

Basic Paxos is generally described as solving consensus for a single value. Real distributed systems, however, need to make many decisions over time. That is why practical implementations often use variants such as Multi-Paxos, extending the approach across a sequence of decisions.

Multi-Paxos can also benefit from a stable leader. Once a leader is established, the system can avoid repeating some coordination work for every new decision.

This is where Paxos can begin to feel more abstract.

Paxos gives you rules for safely reaching agreement, but more of the surrounding replicated-system design is left to the implementation.

Raft: Replicate a Log

Raft approaches the same problem from a more structured direction.

Instead of primarily asking: “Can everyone agree on X?”

Raft encourages you to ask: “Can everyone agree that X belongs at this position in the same ordered history?”

Its core abstraction is an ordered, replicated log.

Client
   ↓
Leader
   ↓
Append to Log
   ↓
Replicate to Followers
   ↓
Majority
   ↓
Commit

A client sends a command to the leader. The leader appends that command to its log and attempts to replicate the new entry to follower nodes.

Once an entry meets Raft's commitment requirements, it becomes committed and can be applied to the replicated state machine.

The ordering matters.

Distributed applications often care about more than agreement on individual values. They need agreement on the sequence of operations that changed the system.

For example, if one command creates a resource and another updates it, applying those commands in different orders could produce different results.

Raft's replicated log gives the system a clear model for maintaining that shared history.

Raft Makes Leader Election Explicit

Raft makes leadership a central part of the protocol.

A node can be in one of three states:

• Follower
• Candidate
• Leader

If followers stop receiving communication from the leader, an election can begin.

Follower
   ↓ timeout
Candidate
   ↓ majority votes
Leader

Leadership is divided into numbered terms.

A newer term supersedes an older one, giving nodes a mechanism for identifying stale leaders and handling leadership changes.

This makes leader election and log replication explicit components of the Raft design.

Paxos can also use stable leaders, particularly in Multi-Paxos, but leadership is not the primary abstraction of classic Paxos in the same way.

Paxos vs Raft: The Key Difference

The simplest mental model is:

Paxos starts with consensus.

Raft starts with a replicated system and structures consensus around it.

Neither is inherently better in every situation.

Both can provide the consensus guarantees needed to build fault-tolerant distributed systems. The practical difference is largely in how they organize the problem and the mental model they give engineers.

Why This Matters for CI/CD Infrastructure

Modern CI/CD infrastructure is distributed by nature.

A single build may involve schedulers, runners, Docker builds, shared caches, artifact storage, databases, and coordination between multiple services.

This is especially relevant when thinking about Docker caching in CI. When multiple runners rely on shared cached layers, several distributed system design questions quickly appear:

• Which version of the cache is current?
• How is cache state shared or replicated?
• What happens when a runner fails?
• How do multiple machines coordinate changes?
• What happens during a network failure or partition?
• How does the system recover when a component becomes available again?

What starts as “make Docker builds faster” can quickly become a distributed systems problem involving consistency, replication, coordination, and failure recovery.

For Monk CI, the broader lesson is simple: faster CI is not only about faster CPUs or more runners. It also depends on efficient caching, reliable coordination, resilient storage, and infrastructure designed to keep working when individual components fail.

See Distributed CI Infrastructure in Action

Understanding distributed systems is useful because the underlying engineering principles eventually show up in real infrastructure.

Whether you're managing build runners, shared caches, artifact storage, or coordination between services, reliability depends on how the system behaves when individual components fail.

Connect your GitHub repository to Monk CI and start running builds on high-performance CI infrastructure.

Distributed systems may begin with Paxos and Raft.

But they eventually return to the same engineering question:

How do we build infrastructure that keeps working when things go wrong?

That’s the problem worth tackling.