Write-Ahead Vote Log¶

Durable write-ahead logging tool — instantiates Assumption-Bounded Distributed Agreement

Forces every vote, promise, and term change onto durable storage before the node acts on it, so a crash-and-restart can never make a participant contradict something it already promised.

Every consensus safety proof quietly assumes a node never forgets or contradicts a vote it has cast — but real machines crash and reboot with empty memory. Write-Ahead Vote Log is the durability tool that makes that assumption actually hold. Before a participant sends any consequential response — a vote, a promise or acknowledgement, a new term number, an accepted value — it first appends that fact to an append-only log on stable storage and flushes it, and only then acts. Its defining rule is the ordering in its name: write ahead of acting, so that after a crash the node replays its log and resumes in a state consistent with every promise it already made, rather than casting a second, conflicting vote. It turns a node that would otherwise be amnesiac after a restart into one whose past commitments survive power loss — the unglamorous substrate the elegant protocols are proven correct on top of.

Example¶

One replica in a five-node replicated log is asked, in term 12, to vote for candidate A. It grants the vote — and a heartbeat later, its power fails. Without durable state, the replica reboots remembering nothing of term 12; if candidate B now asks for a vote in term 12, the replica would innocently grant a second vote, and two leaders could emerge in the same term — a split brain. With a write-ahead vote log, the replica had appended term = 12, votedFor = A and forced it to disk before replying to A. On reboot it replays the log, sees it has already voted in term 12, and refuses B. It likewise replays its accepted log entries so it never acknowledges a rewrite of history it had already durably accepted. The crash becomes invisible to the protocol's safety argument — exactly as that argument assumed.^[1]

How it works¶

Append, flush, then act. The consensus-relevant fact is written to stable storage and fsynced before any message that depends on it leaves the node; the disk write is on the critical path by design.
The log is the authority. Current term, the vote cast this term, and accepted/committed entries live in the log as the node's true state; in-memory copies are just a fast cache of it.
Recover by replay. On restart the node reconstructs its state by replaying the log — optionally starting from the latest snapshot — landing in precisely the state it was in before crashing.
Bound it with snapshots. Periodic checkpoints let the old log prefix be truncated, so the log (and the replay time) does not grow without limit.

Tuning parameters¶

Flush policy — fsync every record (safest, slowest), group-commit several together, or flush asynchronously. Batching amortizes disk latency but risks losing the last unsynced records on a crash — which silently weakens the durability the protocol assumed it had.
Snapshot cadence — how often state is checkpointed so the log can be trimmed. Frequent snapshots shorten restart-replay at a steady I/O cost.
What is logged — minimal metadata (term and vote only) versus the full accepted-entry stream. Logging more supports fuller recovery but enlarges the log and slows each write.
Storage-durability assumption — whether writes truly reach non-volatile media or a controller/OS cache that merely claims they did. The entire guarantee rests on this being honest.

When it helps, and when it misleads¶

Its strength is that it is what lets a crashed participant rejoin without becoming a source of unsafety. The premise every quorum, election, and commit proof leans on — "a node does not contradict its own vote" — is only true across restarts because something forces that state to disk first; this tool is that something.

Its limits are the limits of durability. It protects safety, not liveness: a node blocked on fsync is slower, and the whole point is to trade latency for correctness. The guarantee is exactly as strong as the storage's honesty — a lying write cache, an unsynced tail lost on power failure, or silent disk corruption voids it without warning. And it recovers a node's own promises, not the group's decision, which is a different job. The classic misuse is disabling fsync (or trusting a volatile cache) "for performance," so that after a real power loss the node forgets a vote and the cluster splits — the assumption the protocol was proven safe under has quietly become false. The discipline is to persist consequential state before acting, verify the storage really is durable, and treat any relaxation as a change to the fault model, not a free speedup.

How it implements the components¶

event_log — it is the append-only, durable record of the node's consensus-relevant events (term changes, votes, promises, accepted entries) in the exact order they occurred.
recovery_policy — it defines how a restarted participant returns to a safe state: replay the log (from the latest snapshot) to restore precisely the commitments it had made before the crash.

It does not count votes or decide a value (quorum_or_voting_rule → Quorum or Consensus Commit), package a decision as portable proof (decision_certificate → Signed Quorum Certificate), or restore the group's leadership after a failure (safety_liveness_contract → View-Change Protocol). It keeps one node honest across a crash; the agreement itself is made elsewhere.

Instantiates: Assumption-Bounded Distributed Agreement — it makes the "stable storage" premise every safety proof assumes actually true in the presence of crashes.
Sibling mechanisms: Raft-Style Replicated-Log Protocol · Term/Epoch Leader Election · Quorum or Consensus Commit · Timeout Policy · Byzantine Fault-Tolerant Quorum Protocol · Consensus Fault-Injection Test · Heartbeat and Suspicion Detector · Joint-Consensus Membership Change · Paxos-Style Quorum Protocol · Randomized Common-Coin Protocol · Signed Quorum Certificate · View-Change Protocol

Notes¶

The durability guarantee is only ever as strong as the storage beneath it. "We turned off fsync and it got faster" is not an optimization — it is a silent edit to the assumption budget, moving the system from "survives crashes" to "survives crashes only if the last few writes happened to reach disk." Because the protocols above take stable storage as a premise, weakening it here can void a safety proof made two layers up, with no visible sign until a real power loss triggers it.

References¶

[1] Write-ahead logging — record the intent to disk before performing the action — is the durability discipline formalized by database recovery methods such as ARIES (Mohan and colleagues) and is exactly what consensus algorithms mean when they require "stable storage" for a node's current term, vote, and accepted entries before it responds. Raft and Paxos both depend on this premise for their crash-recovery safety. ↩