What does ACID stand for? Define each property.

ACID is the four-letter contract a transaction makes: Atomicity, Consistency, Isolation, Durability. Each names a different failure it protects you from, and a strong answer ties each property to a concrete mechanism rather than reciting definitions.

Atomicity — all or nothing

A transaction's statements either all take effect or none do. If anything fails — a constraint violation, a crash, an explicit ROLLBACK — the partial work is undone, leaving no half-applied state.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;   -- if the second UPDATE fails, the first is rolled back too

PostgreSQL achieves this with the write-ahead log (WAL) and multi-versioning: uncommitted changes are visible only to their own transaction until COMMIT.

Consistency — constraints hold across the boundary

A transaction moves the database from one valid state to another. Every PRIMARY KEY, FOREIGN KEY, CHECK, NOT NULL, and UNIQUE constraint that held before must hold after. This is partly the database's job (it enforces declared constraints) and partly the application's (it must encode business invariants as constraints or logic). It is the least "mechanical" of the four.

Isolation — concurrent transactions don't corrupt each other

Concurrent transactions behave as if they ran in some serial order — to a degree controlled by the isolation level. This is the property with knobs: Read Committed, Repeatable Read, and Serializable trade isolation strength for concurrency. PostgreSQL implements it with MVCC, so readers and writers don't block each other.

Durability — committed means committed

Once COMMIT returns, the change survives a crash, power loss, or OS panic. PostgreSQL flushes the WAL to disk (an fsync) before acknowledging the commit, so the change can be replayed during crash recovery even if the data pages themselves weren't yet written.