Mastering Database Transactions: From ACID to Distributed Saga

Transaction

A transaction is a logical unit of work in a database management system that guarantees all operations within it either complete fully or have no effect, ensuring the database moves from one consistent state to another.

Database transactions have four properties—Atomicity, Consistency, Isolation, Durability (ACID)—which together define their implementation.

Implementation

For details on MySQL transaction implementation, see the referenced article. Key implementation details include transaction logs and concurrency control mechanisms.

Transaction Log

Transaction logs store each change's ID, affected element, before‑value, and after‑value, enabling rollback (atomicity) and persistence (durability). In InnoDB, there are undo logs (for atomicity) and redo logs (for durability).

Concurrency Control

To balance consistency, isolation, and performance, databases use locking, timestamps, and MVCC. Locks prevent concurrent updates from conflicting; timestamps check for changes before commit; MVCC provides snapshot isolation.

Distributed Transaction

A distributed transaction spans multiple services, requiring ACID across network boundaries where communication can be unreliable, leading to success, failure, or timeout outcomes.

2PC and 3PC

Two‑phase commit (2PC) uses a coordinator to collect votes from participants before committing. If all vote to commit, the coordinator issues a commit; otherwise it aborts. 2PC is a blocking protocol—if the coordinator crashes, participants may wait indefinitely.

Three‑phase commit (3PC) adds a preparation phase and timeout handling to avoid blocking; participants can decide to commit or abort if they do not receive timely responses.

XA Transaction

MySQL’s InnoDB supports XA transactions, which implement 2PC. The transaction manager acts as coordinator, and each resource manager (e.g., a database) participates as a branch.

Resource managers provide access to transactional resources and can commit or roll back.

Transaction managers coordinate the overall distributed transaction across multiple resource managers.

Saga

Saga sacrifices strong ACID guarantees for eventual consistency (BASE). It breaks a long transaction into a series of local transactions, each followed by a compensating action if needed.

LLT

Long‑Lived Transactions (LLT) hold resources for extended periods, increasing the risk of deadlocks. Sagas decompose LLTs into shorter transactions, reducing rollback risk.

Coordination and Orchestration

Saga can be implemented via choreography (decentralized events) or orchestration (central coordinator). Choreography lets each service emit events to trigger downstream local transactions, requiring idempotent, re‑entrant APIs. Orchestration introduces a central saga orchestrator that tracks sub‑tasks, decides on compensation, and retries on timeouts.

Downstream Constraints

Each participant must expose a primary API and a compensating API, support idempotency via a globally unique ID, and allow retries on network failures.

Summary

Saga abandons strict ACID in favor of BASE (Basic Availability, Soft state, Eventual consistency), providing higher throughput and availability for most business scenarios. Strong consistency is rarely required; eventual consistency with compensation usually suffices.

Message Service

Message queues can provide reliable delivery guarantees (At‑Most‑Once, At‑Least‑Once, Exactly‑Once) that help implement distributed transactions by persisting messages and handling retries.

Protocols like AMQP define tx_select, tx_commit, and tx_rollback to manage transactional messaging.

Conclusion

Understanding and applying transaction mechanisms—from 2PC/3PC to Saga and message‑based approaches—is essential for backend developers building reliable microservices.

Source: https://draveness.me/distributed-transaction-principle