What Are ACID Transactions?

What is an ACID transaction?

The acronym was coined by Theo Härder and Andreas Reuter in 1983, formalizing properties Jim Gray had articulated in his earlier work on transaction processing. The problem it addresses is that real operations are rarely single writes: transferring money touches two accounts; placing an order decrements inventory, creates an order row, and records a payment. Without transactions, a crash or a concurrent writer midway through leaves the system in a state no one intended — money debited but never credited, inventory sold twice.

The four properties divide the problem cleanly:

• Atomicity — all of the transaction's writes apply, or none do. Partial results are never visible, even after a crash.
• Consistency — the transaction moves the database from one valid state to another with respect to its declared rules (constraints, foreign keys, invariants).
• Isolation — concurrent transactions do not observe each other's intermediate states. The strictest form, serializability, makes the outcome equivalent to some one-at-a-time execution.
• Durability — once the database acknowledges a commit, the result persists through failures.

How ACID transactions work

The canonical example is a transfer between accounts:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'A';
UPDATE accounts SET balance = balance + 100 WHERE id = 'B';
COMMIT;

If the process crashes between the two updates, atomicity guarantees the debit is rolled back. If another transaction reads during execution, isolation prevents it from seeing A debited while B is not yet credited.

Under the hood, databases implement these guarantees with a few core mechanisms. A write-ahead log records every change before it touches the data files, giving the system what it needs to redo committed work and undo uncommitted work after a crash — that single structure carries most of atomicity and durability. Isolation is enforced either with locks or, in most modern engines, with multi-version concurrency control (MVCC), which lets readers see a stable snapshot while writers proceed. Because full serializability limits concurrency, SQL defines weaker isolation levels (read committed, repeatable read, snapshot isolation) that trade anomaly protection for throughput — most production systems run below serializable, which is itself a source of subtle bugs. When a transaction must span multiple nodes or systems, protocols such as two-phase commit extend atomicity across them, at a significant availability and latency cost.

Why ACID transactions matter in real-time systems

For automated decisions, ACID's most valuable property is arguably isolation: a decision that reads within a transaction sees a self-consistent snapshot — a balance and its ledger entries that actually agree — rather than a mixture of before and after states from concurrent writers.

The critical limitation is that these guarantees end at the boundary of the system enforcing them. Real architectures copy transactional data outward — into Redis caches, Kafka topics, feature stores, analytical warehouses — and none of those copies are covered by the source's transaction. Each downstream copy advances at its own pace. A risk engine that reads an account balance from the OLTP database and a spend-velocity counter from a stream-fed cache is not reading one consistent snapshot, even though every individual system involved may be perfectly ACID. The transactional split that produces this topology is covered in OLTP vs OLAP, and the resulting cross-system drift in the modern data stack's coherence problem.

The practical takeaway: ACID answers "did this group of writes apply correctly, in order, and durably?" It does not answer "do all the systems that derived state from those writes agree right now?" — that is a separate problem, governed by replication and pipeline lag rather than by the transaction protocol.

FAQ