Why Transaction Consistency Matters: From ACID to Distributed Consensus

Transaction Overview

When we talk about transactions, the ACID properties often come to mind, but first we should ask why a database system needs a transaction mechanism at all. Designing a storage system that remains reliable despite software bugs, hardware failures, power loss, network interruptions, or concurrent client conflicts requires a built‑in safety net.

Software, hardware, or configuration faults can occur during any write operation.

Power loss may cause partial writes, raising questions about retry or discard.

Network failures can break the connection between application and database, leaving data incomplete.

Concurrent clients may conflict or overwrite each other's data.

Partial reads can occur when a write is interrupted.

By abstracting these fault scenarios into a mechanism at the storage layer, applications can rely on the database to provide fault‑tolerant safety guarantees, allowing developers to focus on business logic rather than low‑level error handling.

Assessing the safety of a transaction leads us back to the ACID properties, originally defined by Theo Härder and Andreas Reuter in 1983 to give precise semantics for fault tolerance. Here we focus on the "C" – consistency.

Different Consistency Terminology

Consistency appears in several forms:

Replica Consistency and Eventual Consistency arise when replicas communicate asynchronously, introducing replication lag and data divergence. Choosing the appropriate consistency model or applying CAP/BASE theory helps trade off availability and latency.

CAP Consistency (linearizability) describes how a client sees the most recent data in a replicated, high‑availability system.

Consistent hashing is an algorithm that rebalances partitions uniformly based on hash values.

In ACID, Consistency means the database must satisfy application‑specific invariants; it is defined by business rules, not by the DBMS itself.

Premise: User A has 1000, User B has 2000, total 3000. After A transfers 500 to B, balances become 500 and 2500, total remains 3000 – the invariant holds, illustrating ACID Consistency.

This invariant‑based consistency depends on the application defining valid states; the database can enforce constraints like foreign keys, but cannot prevent logically invalid data if the application’s rules are violated.

Distributed Transactions and Atomic Commit

Atomicity means a series of operations either all succeed or all fail. In multithreaded programming, an atomic operation is indivisible – other threads never see a half‑completed state.

For transactions, atomicity ensures that if a failure occurs mid‑operation, the system aborts the transaction and discards all writes, preserving safety across distributed nodes.

The atomic commit problem arises when a transaction spans multiple nodes: some nodes may succeed while others fail. To maintain atomicity, all nodes must agree to either commit or roll back the transaction, achieving consensus.

Revisiting Consensus

Transactions address reliability at a single‑node level, while consensus algorithms provide fault‑tolerant guarantees across distributed systems. Consistency can refer to ACID consistency (application invariants) or replica consistency; distinguishing these helps clarify the underlying guarantees.

Summary

The diagram below contrasts the focus points of transactions, consistency, and consensus, highlighting how each contributes to building fault‑tolerant data‑intensive applications.