ACID properties

ACID describes what you get from a transactional database: all-or-nothing execution, valid state before and after, isolation from concurrent transactions, and durability after commit. Together they keep data consistent and predictable.

The four properties

flowchart TB A[Atomicity: All or nothing] C[Consistency: Rules hold before & after] I[Isolation: Concurrent txns don't see each other's partial state] D[Durability: Committed data survives crash] A --> T[Transaction] C --> T I --> T D --> T

Letter	Meaning	In practice
Atomicity	All or nothing	If any step fails, entire transaction is rolled back
Consistency	Invariants hold	DB constraints (FK, unique, checks) hold after commit
Isolation	Concurrent txns isolated	Controlled by isolation level (see next topic)
Durability	Commit is permanent	Once committed, data persists despite crash

Atomicity in action

sequenceDiagram participant T as Transaction participant DB as Database T->>DB: BEGIN T->>DB: UPDATE accounts SET balance = balance - 100 WHERE id = 1 T->>DB: UPDATE accounts SET balance = balance + 100 WHERE id = 2 alt All OK T->>DB: COMMIT DB-->>T: Durability: written to disk else Error T->>DB: ROLLBACK DB-->>T: All changes undone (Atomicity) end

NoSQL stores often relax ACID (e.g. eventual consistency, single-document transactions) to gain scale. When you need multi-row or multi-document consistency, choose a store that supports ACID or use patterns like Saga with compensating actions.