Distributed Transactions
Distributed transactions coordinate writes across multiple databases or services so they either all commit or all abort, maintaining data consistency. They introduce protocols like two-phase commit and saga patterns that trade off between consistency, availability, and complexity.
itDistributed systems, messaging, and integration | OpenSkills.info
Intro
Distributed Transactions
A local database transaction gives one system a clear boundary. All of its changes commit, or none of them do. That promise becomes harder when one business operation crosses databases, message brokers, or independently deployed services.
A distributed transaction coordinates changes across more than one transactional resource. The central question is not how to send several requests. It is how every participant reaches a safe final outcome when messages, processes, or machines fail.
Consider an order that reserves inventory and records a payment. A crash after only one change can leave the business state inconsistent. Retrying the whole request can create a second payment. Waiting forever can preserve safety while making the order unavailable.
Distributed transaction design is therefore a choice among guarantees, failure behavior, latency, coupling, and operational cost.
The core mental model
Separate the business operation from each local transaction.
- The business operation describes the outcome you need, such as placing an order.
- A local transaction commits changes inside one resource manager.
- A coordination protocol connects those local outcomes.
- Recovery logic decides what happens after partial progress or uncertain communication.
The network creates an ambiguity that local code cannot remove. After sending a commit request, a coordinator might lose the reply. The participant may have committed, or the request may never have arrived. A timeout reports uncertainty, not the transaction outcome.
That uncertainty drives the two main families of designs:
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.ibm.com/docs/en/txseries/11.1.0?topic=processing-two-phase-commit-process
Supports
- Distributed transactions spanning processes and machines
- Coordinator and participant roles
- Recoverable process logs
- Prepare votes, durable promises, and final resolution
- Atomic commit despite component and communication failures
- https://www.ibm.com/docs/en/iis/11.5.0?topic=overview-distributed-transaction-processing-model
Supports
- X/Open application, transaction manager, and resource manager roles
- XA as the transaction-manager and resource-manager interface
- Prepare and commit phase behavior
- https://www.postgresql.org/docs/current/sql-prepare-transaction.html
Supports
- PostgreSQL prepared transaction behavior and recovery commands
- External transaction manager as the intended caller
- Prepared transactions retaining locks and delaying storage cleanup
- Recommendation to resolve prepared transactions promptly
- https://www.postgresql.org/docs/current/two-phase.html
Supports
- PostgreSQL support for two-phase commit
- Relationship to the X/Open XA model
- Inspection of prepared transactions
- https://www.microsoft.com/en-us/research/publication/consensus-on-transaction-commit/
Supports
- Relationship between consensus and transaction commit
- Ordinary two-phase commit blocking behavior
- Two-phase commit as lacking coordinator fault tolerance
- Paxos Commit using consensus for participant outcomes
- https://learn.microsoft.com/en-us/azure/architecture/patterns/saga
Supports
- Saga as a sequence of local transactions
- Compensable, pivot, and retryable steps
- Choreography and orchestration coordination styles
- Saga benefits, drawbacks, and observable intermediate states
- https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction
Supports
- Compensation as application-specific recovery work
- Compensation ordering, parallelism, idempotency, and resumption
- Compensation failure and manual intervention
- Compensation not necessarily restoring the exact starting state
- https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html
Supports
- Database-and-message dual-write failure modes
- Atomic storage of business data and outgoing message intent
- Outbox table and relay architecture
- Duplicate messages, ordering, and idempotent consumers
- Saga orchestration for operations spanning service data stores