Does a distributed transaction require different organizations?

No. It may span partitions or nodes inside one database service operated by one organization.

Can a client receive a timeout after a successful commit?

Yes. The acknowledgment may be delayed or lost. The client needs the system's supported way to handle an uncertain outcome.

Is a saga equivalent to an atomic distributed transaction?

No. A saga coordinates a sequence of committed local actions and compensations. Intermediate states and compensation failures must be handled as business behavior.

AI Glossary / Data engineering and architecture / Intermediate

Distributed transaction

Definition

A distributed transaction is a transaction whose work involves more than one networked resource or database participant. In the atomic-transaction sense, the participants coordinate so the transaction has a consistent commit or abort outcome rather than leaving only some of its intended changes committed.

What it means

A transaction groups related operations into a defined unit of work. Distribution arises when the required changes are handled by different nodes, partitions or resource managers. The application wants the operation to have meaningful overall behavior even if messages are delayed or a participant fails.

Atomicity concerns the all-or-nothing outcome. Isolation concerns how the transaction interacts with other concurrent transactions. Durability concerns the persistence of a committed result. A distributed commit protocol addresses part of this picture; its existence alone does not establish every database guarantee.

The term is sometimes used broadly for a business workflow spanning services. Such a workflow may use a saga with compensating actions instead of an atomic transaction. These approaches should be named clearly because their intermediate visibility and failure behavior differ.

How it works

A coordinator and participants follow the selected transaction protocol. In the familiar two-phase commit approach, the coordinator first asks participants whether they can prepare to commit. A participant that votes yes must preserve enough state to honor the eventual decision rather than casually changing its mind.

If the requirements for commitment are met, the coordinator records and communicates the commit decision; otherwise the outcome is abort. Logging and recovery rules allow participants to resolve the transaction after interruptions. Some failures can leave participants waiting because they cannot yet establish the decision safely.

Other protocols or database designs may organize coordination differently. Applications must follow the actual interface, including retry and outcome-checking rules. A client timeout does not necessarily mean the transaction aborted. Repeating the business operation with a new identity can duplicate work if the original committed but its reply was lost.

Three practical examples

A database transaction updates related records in two partitions and coordinates their outcome through the database's distributed transaction mechanism.
An enterprise system uses participating resource managers to coordinate a database change with another supported transactional resource.
A multi-site reservation service evaluates whether related reservations need one atomic outcome or a business workflow with explicit compensations and temporary intermediate states.

Think of it this way

Think of two offices agreeing to make a paired change only after both can commit to the plan. Once an office has formally promised to follow the final decision, losing contact does not entitle it to invent a different outcome.

Real transaction protocols provide durable records and precise recovery rules that the office analogy omits. The point is the difficult interval between being ready and knowing the final decision.

Worked example

Consider a fictional stock transfer recorded in two database partitions. Site A's inventory starts at 40 units and site B's at 10. The transaction should subtract 6 from A and add 6 to B, producing 34 and 16. The combined recorded stock remains 50.

If A's subtraction commits but B's addition does not, the records total 44. If only B's addition commits, they total 56. An atomic distributed transaction is intended to prevent these partial committed outcomes within its supported scope.

Now suppose both changes commit but the client loses the acknowledgment. The database can still be correct while the client is uncertain. Blindly issuing a new transfer would produce another change. An operation identifier and an appropriate outcome-recovery process help the application distinguish retrying a request from authorizing a second transfer.

Illustrative case study

Fictional case: a rental platform needs to reserve a vehicle and a specialized accessory maintained in separate transactional partitions. Its evaluation checks whether the database can include both records in one supported transaction.

The team tests participant failures, lost client replies and contention. It confirms that retries rerun the transaction's required checks, and that a confirmed reservation notification is issued through a process designed to avoid duplicates or lost messages. An ordinary email send is not assumed to become reversible merely because the database rolls back.

Where an external supplier cannot join the atomic protocol, the team specifies a separate workflow with cancellation rules and visible pending status. The scenario distinguishes transactional guarantees from business actions outside their scope.

Common misconceptions and mistakes

Common mistakes include confusing two-phase commit with two-phase locking, assuming that an atomic transaction makes all external actions reversible, and treating a timeout as proof of failure. The words commit, locking and timeout address different parts of system behavior.

Another error is calling compensating actions a rollback in the database sense. A cancellation is a new business action and may not erase intermediate effects. Finally, a long-running distributed transaction can hold resources and increase contention, so transaction scope deserves careful design.

Business use

Businesses should identify which changes truly require a shared atomic outcome and whether all relevant resources support the necessary protocol. Evaluate latency, failure recovery, contention and operational visibility alongside correctness.

For an AI agent using tools, a sequence of successful calls is not automatically one distributed transaction. The agent may create a record and then fail before completing a related action. Tool and workflow design must provide the required atomicity, idempotency or compensation explicitly. Prompt instructions alone cannot supply database-level guarantees.

Check your understanding

A database transaction commits a booking, but sending a confirmation email fails. Does the transaction's atomicity automatically undo the email attempt and cancel the booking?

Answer: No. Only participating operations inside the transaction's defined scope receive its guarantees. External messaging needs its own coordinated delivery and recovery design.

Related terms

Atomicity (database systems)
Isolation (database systems)
Durability (database systems)
Atomicity
two-phase commit
transaction coordinator
participant
isolation
durability
saga
compensation
idempotency
transactional outbox

Learn next

study two-phase commit's prepared state and recovery rules. Then compare atomic transactions with sagas and the transactional outbox pattern. Draw the boundary around which actions your system can actually commit together before choosing a coordination method.

Sources

Bernstein, Hadzilacos and Goodman, Concurrency Control and Recovery in Database Systems, Chapter 7: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/05/chapter7.pdf . Relevant primary text reviewed on atomic commitment and partial failure. Google Cloud, Life of Spanner Reads and Writes: https://docs.cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes . Primary example of multi-partition transaction coordination. Amazon Builders' Library, Challenges with distributed systems: https://aws.amazon.com/builders-library/challenges-with-distributed-systems/ . Primary explanation of uncertain request outcomes.

Previous: Distributed source coding Next: Distributed tree search