What are the ACID properties in databases?

ACID properties ensure reliable database transaction processing: (1) Atomicity: a transaction is an all-or-nothing unit. Either ALL operations in the transaction succeed and are committed, or ALL are rolled back. No partial transactions. Example: bank transfer — debit and credit must both happen or neither; (2) Consistency: a transaction brings the database from one valid state to another valid state, respecting all defined rules (constraints, triggers, cascades). Data integrity is always maintained; (3) Isolation: concurrent transactions execute independently — intermediate states are invisible to other transactions. Four isolation levels: Read Uncommitted, Read Committed, Repeatable Read, Serializable. Higher isolation = more consistency, less concurrency; (4) Durability: once a transaction is committed, it persists even if the system crashes. Achieved via write-ahead logging (WAL) — changes are written to a log before being applied. ACID vs BASE: ACID is the philosophy of traditional relational databases (MySQL, PostgreSQL, Oracle). BASE (Basically Available, Soft-state, Eventually consistent) is the philosophy of many NoSQL databases that sacrifice strict consistency for availability and performance. Distributed ACID: ACID across multiple services/databases requires distributed transactions — 2-Phase Commit (2PC) provides this but is slow and has failure modes. Saga pattern provides eventual consistency across services without distributed locks.