WAL ≠ Replicated Log

In my last blog, we looked at how the Write-Ahead Log (WAL) underpins durability across different replication designs. But it’s equally important to understand why, in the world of consensus, the same idea is called a replicated log instead.

A Write-Ahead Log (WAL) remembers what happened locally. A replicated log decides what happened globally. And that difference defines the boundary between replication and consensus.

Every node, leader or follower, maintains a WAL for durability. If it crashes, it can replay the log and restore its last consistent state. But the WAL itself says nothing about what other replicas have done, or in what order. Each node could have the same entries in different sequences and that’s still fine for durability.

In consensus systems, the log gets an upgrade. Each log entry is proposed by a leader and accepted by a quorum before being marked committed. Only after a majority has persisted it does it become part of the replicated log.

That’s what “replicated log” means in papers like Paxos Made Simple or Raft: In Search of an Understandable Consensus Algorithm:

A replicated log is a globally agreed sequence of operations.

It’s a WAL plus:
• Ordering agreement i.e., everyone commits the same entries in the same order
• Fault tolerance achieved via majority-based voting
• Linearizability, the client-facing guarantee, that emerges from this total order when the leader waits for commitment before replying to clients

This is why calling it just “a WAL” would be misleading. A replicated log isn’t just durable; it’s consistently durable everywhere.