Commit-Log Recovery Replay¶
Recovery protocol — instantiates Nested and Distributed Transaction Coordination
Durably logs every coordination decision before it is acted on, so that after a crash the in-flight transactions can be replayed forward and driven to a definite committed, aborted, or compensated end.
A distributed transaction is dangerous precisely at the moment a coordinator forgets what it was doing. Commit-Log Recovery Replay removes memory from the critical path: every decision the coordinator makes — prepared participant A, committing participant B, aborting, compensating — is appended to a durable log before the corresponding action is issued, so the log, not RAM, is the authoritative account of where each transaction stood. When the coordinator crashes and restarts with an empty memory, it scans the log forward, finds every transaction that lacks a terminal record, and re-drives each one to a definite outcome. Its defining idea is that recovery is deterministic replay of a durable decision record, not reconstruction from guesswork — which is what distinguishes it from a mechanism that merely stores outbound messages to publish later.
Example¶
A telecom provisioning coordinator activates a new phone number, which requires coordinated changes in three autonomous systems: the billing platform opens an account, the SIM registry binds the number to a card, and the network switch routes calls. The coordinator writes to its log "prepared: billing; prepared: SIM; committing: switch…" and then the host loses power mid-write. On restart it holds no in-memory state at all — but the log shows a transaction whose last entry is committing: switch with no terminal committed record. Replay re-issues the commit to the switch, observes the acknowledgement, appends committed, and closes the transaction. A second number, whose last log entry read prepare failed: SIM, is replayed straight to abort: the coordinator releases the already-prepared billing account and records the transaction closed. Neither number is left half-provisioned, and no operator had to guess which stuck transaction meant what.
How it works¶
- Write-ahead discipline. The decision is logged and flushed to durable storage before the action is sent to the participant. If the log record survives, the intent is recoverable; if it does not, the action never happened.
- Scan for the unfinished. On restart the coordinator reads the log and collects every transaction with no terminal (committed / aborted / compensated) entry — these are the ones whose fate is unknown.
- Re-drive to a terminal state. Each unfinished transaction is pushed forward along the path its last record implies: resend the pending commit, or run the abort/compensation. Because a re-sent action may reach a participant that already applied it, replay leans on downstream idempotency so the repeat is harmless.
- Checkpoint and truncate. Periodic checkpoints mark how far replay must ever look back, so the log can be trimmed and restart stays fast.
Tuning parameters¶
- Durability granularity — flush every record synchronously (
fsync) or batch flushes. Per-record durability means "logged" truly means "survivable," at real latency cost; batching is faster but widens the window where a decision is lost. - Checkpoint interval — how often state is snapshotted. Frequent checkpoints make restart cheap but add steady-state overhead.
- Replay concurrency — how many stranded transactions are re-driven in parallel on restart; trades recovery speed against load on freshly-restarted participants.
- Retention window — how long closed transactions stay in the log before truncation; longer retention aids forensic audit but grows storage.
- Idempotency reliance — how strongly replay assumes downstream operations tolerate a repeat; the weaker that assumption, the more pre-checking replay must do before re-issuing.
When it helps, and when it misleads¶
Its strength is turning a crash from a catastrophe into a resumable event: any coordinator failure resolves to a bounded scan-and-continue rather than a manual hunt for orphaned work. The technique is the distributed-transaction descendant of write-ahead logging.[1]
Its central failure mode is that replay is only safe when the actions it re-issues are idempotent. Re-sending a commit to a participant that already committed is fine only if that participant deduplicates; against a non-idempotent endpoint, recovery double-executes — a replayed payment charges twice. The classic misuse is treating the commit log as a human audit surface and reasoning about business status from it, when it is machine-recovery scaffolding written in the coordinator's own terms. The guarding discipline is to pair replay with an explicit idempotency safeguard on every re-issuable action, and to test crash-and-restart at every step of the protocol, not just the convenient ones.
How it implements the components¶
participant_commitment_registry— the append-only log is the durable per-participant record of prepare / commit / abort, the single place the coordinator trusts about who has done what.failure_timeout_and_partition_model— it defines crash-and-restart semantics precisely: a missing terminal record means "unresolved," and replay is the specified resolution.observability_and_audit_trace— the ordered log doubles as the authoritative, time-ordered trace of every coordination decision.
It does not guarantee that a replayed action lands exactly once (idempotency_and_replay_safeguard) — it relies on Idempotency Key & Deduplication Store for that — and it holds no human-driven compensation_and_reconciliation_plan for the transactions replay still cannot resolve, which is the job of Manual Reconciliation Workbench.
Related¶
- Instantiates: Nested and Distributed Transaction Coordination — this is the recovery backbone that makes every other protocol crash-survivable.
- Consumes: Idempotency Key & Deduplication Store supplies the exactly-once guarantee that lets replay re-issue actions safely.
- Sibling mechanisms: Saga Orchestration · Saga Choreography · Escrow or Reservation Hold · Transactional Outbox/Inbox Pattern · Manual Reconciliation Workbench · Idempotency Key & Deduplication Store · Quorum or Consensus Commit
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: The runtime writes coordination intent before action, scans durable state after a crash, and automatically re-drives each unfinished transaction to committed, aborted, or compensated completion, so its operative form is recovery control.
Nearest alternative: Protocol, Workflow & Routine — The recovery logic follows an ordered sequence, but executable restart-time detection and replay control live transaction state rather than merely prescribing operator steps.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Database recovery and distributed transaction engineering established write-ahead decision logging and deterministic replay to terminal commit, abort, or compensation.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Its nearest cousin is the Transactional Outbox/Inbox Pattern: both center on a durable log. The difference is what the log holds and who reads it. Commit-Log Recovery Replay logs the coordinator's own decisions so it can resume after a crash; the outbox logs outbound messages so a relay can deliver them to other services without loss. One is for recovering a transaction; the other is for reliably publishing an event.
References¶
[1] Write-ahead logging — record the intended change durably before applying it, so recovery can redo or undo from the log — is the foundational database-recovery discipline, formalized for fine-grained concurrent recovery in the ARIES method (Mohan et al., 1992). Commit-Log Recovery Replay applies the same "log the intent, replay to recover" principle to a multi-participant coordinator rather than a single database. withdrawn registry ↩