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.[n1]
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 —
fsyncevery 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.
Related¶
- 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
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Write-Ahead Vote Log operates as a persistent ledger, log, register, or case record that preserves history and traceability because it 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.
Independent corroboration: The frozen evidence defines Write-Ahead Vote Log as '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', so its operative form is Record, Log & Register.
Nearest alternative: Rule, Policy & Commitment — Write-Ahead Vote Log includes features of a standing rule, threshold, contractual commitment, or policy constraint governing future conduct, but its defining operation is a persistent ledger, log, register, or case record that preserves history and traceability.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Write ahead vote log is rooted in computer science's formal languages, software, data structures, and automation tradition; historically that field developed the defining operation described here: 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.
Related originating lineages:
- Engineering & Design — Engineering's quality, reliability, interface, and lifecycle tradition supplies an independent formative lineage for the mechanism's write ahead vote log logic.
- Security Studies & Intelligence Analysis — Security engineering, threat analysis, and intelligence practice has a distinct contributing or parallel lineage for the mechanism's defining operation: 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.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics has a distinct contributing or parallel lineage for the mechanism's defining operation: 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.
Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined evidence shows material contributions from several lineages. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
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.
[n1] 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. ↩