When one process must change more than one database, a team needs a way to record completed steps and reverse their effects if a later step fails. A Saga provides that pattern through a sequence of local transactions and compensating actions, not through one global ACID rollback.
A Saga orchestrates local transactions
Each Saga step runs a transaction on one destination. When it succeeds, status and recovery information are recorded before the workflow moves to the next target. The Saga completes when every step succeeds. If one fails, compensation runs for completed steps in reverse order.
This pattern accepts that distributed systems lack one universal transaction manager. While processing continues, databases can temporarily disagree. Business design must determine whether that state may be visible and how consumers distinguish pending, completed, compensating, and recovery-required states.
Compensation is not always a delete
If a Saga creates a record, compensation may delete it using a precise identity. For an update, compensation can restore a snapshot of the previous values. Recovering a delete requires enough data to recreate the record and its relationships. Sometimes the correct business action is not to erase a change but to create a reversal entry that preserves audit history.
| Initial step | Possible compensation | Important question |
|---|---|---|
| Insert | Delete by stable ID | Has another process used the record? |
| Update | Restore snapshot | Was the value changed again afterward? |
| Delete | Reinsert snapshot | Are all children and constraints available? |
| Financial posting | Reversal entry | Does audit policy prohibit deletion? |
The journal is the recovery evidence
A Saga journal connects at least a correlation ID, step order, destination, operation, status, and compensation material. It must be sufficient to resume recovery idempotently after a restart. Because snapshots may contain sensitive data, the journal should be encrypted, access-controlled, and deleted under an agreed retention policy.
A visual integration platform creates an encrypted compensation journal for a cross-store transaction orchestration and runs automatic compensation without requiring the user to design a reverse query for every step. Preflight checks schemas before execution. That automation reduces configuration, but it does not change distributed-system reality: destination state must still be verified.
Example: a sales transaction and reporting database
- Write the primary transaction.
The transaction database stores an invoice with a stable correlation ID.
- Write the reporting projection.
The reporting database receives the required summary rather than all sensitive data.
- The second target fails.
The Saga stops later steps and reads the journal for the first step.
- Run compensation.
The first change is reversed using the recorded identity or snapshot.
- Verify the final state.
Completion is recorded only after both destinations and the journal agree.
In many architectures, a reporting database is allowed to catch up. Eventual consistency with measured retries can be simpler than cancelling a sale. A Saga should be selected because of a business invariant, not merely because a workflow touches two databases.
When compensation does not complete
A network may fail during compensation, or another process may have changed the record. A visual integration platform marks the Saga as a status requiring manual recovery when automatic recovery cannot be proven complete. An operator must review the correlation ID, step states, and actual destination records before retrying or applying a manual correction.
- Do not report success merely because the initial error was caught.
- Make compensation idempotent so repeating it does not corrupt data.
- Separate automatic authority from high-risk business decisions.
- Prepare an alert and runbook for every state that requires recovery.
Define who may initiate and complete recovery. Automatic compensation for low-risk operational data differs from a financial reversal, stock release, or legal-document cancellation. Some steps may require approval or should only create a task for an authorized role. The workflow must stop at that boundary, provide sufficient evidence, and avoid making a domain decision it has not been delegated.
Monitor Saga age, the last completed step, compensation retry count, and a status requiring manual recovery volume. These metrics are more useful than a simple failure count because they show unresolved recovery work. Reconcile journals with destinations periodically so stalled Sagas do not remain hidden. Journal retention must support investigation and recovery without keeping sensitive snapshots longer than needed.
When is a Saga appropriate?
If compensation cannot be defined or effects include external APIs or email, use idempotency, pending states, and reconciliation instead of promising complete rollback.
Before activation, test failure at every step and test compensation failure itself. Start with the limits of cross-database rollback and single-connection ACID so the architectural choice remains honest.
This discussion describes a general industry pattern, not a particular product implementation. If the team is comparing options, NitroNet can be included as one evaluation candidate and should still be tested against the organization’s needs, risks, and operating readiness.