Rollback Transaction¶
Transactional recovery — instantiates Invariant Guarding
When a change fails its invariant check partway through, returns the system to a known-good state instead of leaving a partial or invalid result committed.
A Rollback Transaction is the response side of the archetype: when a proposed change fails its invariant check partway through, it returns the system to a known-good prior state instead of leaving a partial or invalid result committed. Its defining move is that it does not decide whether the invariant is broken — some guard does that — it acts once a break is detected, undoing or compensating the in-flight work so the system lands on a valid state. It owns recovery, not detection: give it a fired violation, and its job is to make the half-done change as if it never happened.
Example¶
Booking a trip takes three steps across separate services: reserve a seat, charge the card, issue the ticket. The invariant is that a customer is never charged without a confirmed seat and ticket, and a seat is never held without payment. Midway through one booking, the seat is reserved and the card is charged, but ticket issuance fails on an inventory race. A naïve system would leave a charged customer with no ticket and a phantom seat hold — an impossible, invalid state someone would have to untangle by hand. The Rollback Transaction instead runs compensating actions in reverse: it voids the charge and releases the seat, returning to the pre-booking valid state, and records what it undid. The customer sees a clean "couldn't complete — nothing was charged" instead of a half-finished mess, and the ledger and inventory are left consistent.
How it works¶
- Triggered by a failed check. A guard or monitor detects that the transition would break (or has broken) the invariant, and hands off to the rollback.
- Undo, atomically where possible. In a single store, aborting the transaction lets the engine's undo restore the prior state exactly.
- Compensate across distributed steps. Where steps span services or already committed, compensating actions undo each in reverse — the saga approach — since there is no single engine to roll back.
- Record the recovery. The rollback, its trigger, and the restored state are logged so the failure stays visible; the why remains with the guard that fired.
Tuning parameters¶
- Rollback vs. repair — full undo to the prior state vs. forward-repair to a corrected valid state. Undo is clean; repair salvages progress but can mask the underlying cause.
- Compensation completeness — how fully the side effects are reversible. Some effects (a sent email) are not, and any gap leaves residue.
- Savepoint granularity — how far back to roll: the whole transaction or the last checkpoint. Finer savepoints save work but add bookkeeping.
- Retry policy — whether a rolled-back transition is automatically retried, and how many times, before it is surfaced to a human.
When it helps, and when it misleads¶
Its strength is guaranteeing the system lands on a valid state even when a multi-step change fails partway — which is what makes atomicity real — and the saga pattern extends that guarantee to distributed steps that lack a single engine to undo them.[n1]
Its central failure mode is reliance past the point of irreversibility: rollback assumes the steps can be undone, but once an irreversible effect has fired — funds wired externally, an email sent, a physical item shipped — there is nothing to roll back to, and a "rollback" silently leaves that effect standing. The classic misuse is trusting rollback to clean up after a step with external, non-compensable side effects, so the invariant looks "restored" in the database while the real-world violation persists. The guarding discipline is to place the detecting guard before the irreversible step wherever possible, and to design compensations honestly — knowing exactly which effects truly cannot be undone.
How it implements the components¶
violation_response_path— it is the "roll back" branch taken when a transition would break the invariant, one of the archetype's defined responses.rollback_or_repair_policy— its core: restoring a valid prior state through undo, or repairing the transition forward when a valid correction exists.audit_trace— it records the rollback, the trigger that fired it, and the restored state.
It acts on a break it did not detect; it does not itself judge whether the invariant holds (guard_condition, validation_rule) the way a Contract Check does, nor watch for slow drift via monitoring_signal (that's Integrity Monitor).
Related¶
- Instantiates: Invariant Guarding — the Rollback Transaction is the recover-to-a-valid-state realization of the archetype.
- Consumes: Contract Check or Database Constraint — supplies the fired-violation trigger this responds to.
- Sibling mechanisms: Database Constraint · Safety Interlock · Invariant Test Suite · Contract Check · Policy Guardrail · Integrity Monitor · Two-Person Rule
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Rollback Transaction operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it when a change fails its invariant check partway through, returns the system to a known-good state instead of leaving a partial or invalid result committed.
Independent corroboration: The frozen evidence defines Rollback Transaction as 'When a change fails its invariant check partway through, returns the system to a known-good state instead of leaving a partial or invalid result committed', so its operative form is Control, Automation & Runtime.
Nearest alternative: Protocol, Workflow & Routine — Rollback Transaction includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Atomic transaction rollback after invariant failure is a canonical database mechanism.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: when a change fails its invariant check partway through, returns the system to a known-good state instead of leaving a partial or invalid result committed.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement starts from reviewer_a’s mechanism-specific evidence: Atomic transaction rollback after invariant failure is a canonical database mechanism. Reviewer A proposed alternates=none, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false; reviewer B proposed alternates=engineering_design, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false. The final record retains every independently supported alternate from either review (engineering_design) without an arbitrary cap, selects origin_mode=single_lineage to represent the combined lineage evidence, and keeps domain_reach=specialized and encyclopedia_synthesis=false from the more mechanism-specific assessment. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
It is easily confused with the Integrity Monitor, since both operate after the transition. The one-sentence separation: a Rollback Transaction restores a valid state in response to a detected break, while an Integrity Monitor only detects and records the break and takes no corrective action.
[n1] Saga pattern — for a transaction spanning multiple services that cannot share one atomic commit, each step is paired with a compensating action; on failure, the already-completed steps are undone in reverse to restore consistency. ↩