Understanding Local and Global Transactions, Consistency Models, and Distributed Transaction Patterns

From monolithic to micro‑service architectures, system interactions become increasingly complex, making data consistency a critical challenge. Data self‑consistency requires that data can validate its own accuracy and meet business expectations.

Local Transactions

Traditional relational databases ensure consistency via ACID properties:

Atomicity : all operations succeed or all fail.

Consistency : the system remains in a valid state.

Isolation : transactions appear to run alone.

Durability : committed changes persist.

These properties rely on write‑ahead logging and lock mechanisms (write lock, read lock, range lock) to provide isolation levels such as Serializable, Repeatable Read, Read Committed, and Read Uncommitted.

Global Transactions

When a request spans multiple databases, the X/Open XA architecture introduces a Transaction Manager and Resource Managers, coordinated through the Two‑Phase Commit (2PC) protocol. 2PC follows five steps: begin, prepare, collect votes, commit/rollback, and finalization.

2PC suffers from single‑point‑of‑failure, performance, and consistency risks, leading to the development of Three‑Phase Commit (3PC) which adds a CanCommit and PreCommit stage to mitigate these issues.

CAP and BASE Theories

The CAP theorem states that a distributed system can simultaneously satisfy only two of Consistency, Availability, and Partition tolerance. Choosing CP or AP leads to different trade‑offs, with AP often adopting eventual consistency.

BASE (Basically Available, Soft state, Eventual consistency) expands on this, describing practical consistency models such as causal consistency, read‑your‑writes, session consistency, monotonic read/write consistency.

Implementation Patterns

Reliable Event Pattern

Events are persisted in a local transaction, then a message service polls and delivers them, ensuring best‑effort delivery through retries and idempotent handling.

TCC (Try‑Confirm‑Cancel)

TCC splits a business operation into Try (resource reservation), Confirm (final execution), and Cancel (rollback), requiring idempotency and compensating actions.

SAGA Pattern

SAGA breaks a long‑running transaction into a series of local sub‑transactions with corresponding compensating actions, supporting forward or backward recovery strategies.

Conclusion

The article summarizes local and global transaction mechanisms, consistency theories, and practical patterns (reliable events, TCC, SAGA) for achieving data self‑consistency in modern micro‑service architectures.