Understanding Consistency in Distributed Transactions: Strong vs. Weak, CAP Theory, and NewSQL Approaches

Distributed transactions are used to solve data consistency problems across databases and services; this article explains what consistency means, the difference between strong and weak consistency, and how it relates to the CAP theorem.

In database theory, transactions have the ACID properties: Atomicity, Consistency, Isolation, and Durability.

Atomicity: all operations in a transaction either complete fully or not at all.

Consistency: the database integrity (foreign keys, constraints, etc.) is preserved before and after the transaction.

Isolation: concurrent transactions do not interfere with each other.

Durability: once a transaction commits, its changes survive failures.

Using a concrete transfer example (A transfers 30 to B), a local transaction ensures the total amount A+B remains unchanged throughout, which is considered strong consistency.

When business logic spans multiple databases and micro‑services, the consistency concern becomes that of distributed transactions.

In a single‑node local transaction, the total amount stays constant under ReadCommitted or RepeatableRead isolation levels, representing strong consistency.

Cannot Achieve Strong Consistency

In real cross‑database or cross‑service scenarios, no practical solution provides strong consistency. The XA transaction diagram below shows that a query at a certain point returns A+B+30, which violates strong consistency.

Theoretical Strong Consistency

If we set the isolation level of the databases involved in an XA transaction to Serializable, we might expect strong consistency. The following diagram shows the result, but a query can still return A+B‑30, which is inconsistent.

To achieve strong consistency theoretically, we can:

Use XA for queries and employ SELECT FOR UPDATE so that all data is locked until the XA commit.

Order database access consistently across services to avoid deadlocks.

With this strategy, any query at any point in the timeline returns the correct total A+B.

At time T0, the query occurs after all modifications, returning A+B.

At times T1, T2, T3, queries also occur after modifications, returning A+B.

This theoretical strong consistency is extremely inefficient because all intersecting database transactions must execute serially and in a fixed order, making it impractical for production.

NewSQL Strong Consistency

Distributed transactions that operate within a single data store can achieve strong consistency using MVCC, similar to single‑node databases but more complex; Google’s Percolator is an example. Future systems may adopt NewSQL techniques to provide strong consistency for cross‑database or cross‑service transactions.

Implementing cross‑service (but not cross‑database) consistency can be simpler by adding the XA TMRESUME option, ensuring only one XA commit.

Achieving cross‑database consistency is much harder because each database has different internal version mechanisms.

Weak Consistency Classification

Since existing distributed‑transaction solutions cannot provide strong consistency, we classify weak consistency levels as follows:

From strongest to weakest: XA > Message > TCC > SAGA.

“Message” refers to local‑message‑table based distributed transactions. See the classic seven solutions for distributed transactions for details.

No intermediate state: data only has pre‑transaction and post‑transaction states (XA, Message).

Has intermediate state: TCC’s Try phase and SAGA’s compensation phase create states different from both before and after.

XA provides the best consistency among distributed transactions because the inconsistency window is very short (typically <10 ms).

Message‑based transactions have a longer inconsistency window.

TCC’s intermediate state is controllable and usually hidden from users, offering better consistency than SAGA.

SAGA may expose forward‑operation data to users during rollback, resulting in the poorest consistency.

These classifications are based on the dimensions we care about and may not cover every scenario; some implementations can make TCC as consistent as XA.

Consistency in the CAP Theory

The consistency discussed here refers to database consistency, which differs from CAP consistency.

CAP strong consistency means a read after a write returns the latest version, just like a local read/write.

Distributed‑transaction strong consistency means that during the transaction, reads always satisfy business constraints; current practical solutions cannot achieve this.

Although the meanings differ, both aim for the user to experience the system as if it were a single‑node environment.

Readers often wonder how CAP consistency applies to distributed transactions.

Paxos/Raft consensus protocols can elect a new leader within hundreds of milliseconds to a few seconds after failures, allowing systems to choose CP (consistent and partition‑tolerant) at the cost of brief unavailability.

Therefore, data‑sensitive applications like NewSQL or distributed transaction frameworks typically choose CP, sacrificing only a few hundred milliseconds of availability. For example, the dtm distributed‑transaction framework stores global transaction progress in a CP database.

Conclusion

This article thoroughly analyzes consistency issues in distributed transactions, confirms the lack of practical strong‑consistency solutions, classifies weak‑consistency models, and discusses theoretical possibilities for achieving strong consistency.