Transactions & Concurrency

Transactions and ACID

A transaction is an application-chosen unit of work with an atomic commit outcome. ACID describes useful boundaries, but the database cannot invent business consistency rules and durability is always relative to the acknowledged failure model.

Atomicity is all-or-abort, not concurrency isolation.
Consistency is shared responsibility.
Isolation constrains concurrent histories.
Durability has a failure boundary.
Transaction boundaries are semantic.
Abort is a normal outcome.

One transfer, one boundary

Starting state, transition, and invariant

Start: account A = 100; account B = 40; invariant: A + B = 140.
T1: debit A by 30; credit B by 30; COMMIT.
Committed result: A = 70; B = 70; invariant still 140.
Crash after debit: recovery must expose either start or committed result, never A = 70, B = 40.

What ACID does—and does not—assign
Property	Engine mechanism	Application obligation
Atomicity	Undo/redo and atomic commit decision	Put all required writes in one boundary
Consistency	Declared constraints and correct recovery	Declare and preserve business invariants
Isolation	Locks, versions, validation, aborts	Choose level and handle allowed outcomes
Durability	Log/flush/replication policy	Define required failure scope and backups

A successful commit says the database accepted the transition under its configured guarantees. It does not prove that transferring 30 was authorized, that an email was sent exactly once, or that a replica in another region has persisted it.