ACID describes what a transaction guarantees. Atomicity: all operations in the transaction commit together or none do (rollback on failure). Consistency: the database moves from one valid state to another; constraints (e.g. foreign keys) hold. Isolation: concurrent transactions do not see each other’s uncommitted changes in a way that breaks correctness. Durability: once committed, data survives crashes (written to durable storage).

Without transactions, a partial update (e.g. debit one account but fail before crediting another) leaves the system inconsistent. Transactions let you group steps and get all-or-nothing behavior.

Isolation levels control how much one transaction sees of another’s uncommitted or committed work. Read uncommitted: see uncommitted changes (rarely used). Read committed: see only committed data; default in many DBs. Repeatable read: same query in the same transaction returns same rows even if others commit changes. Serializable: transactions behave as if run one after another; strongest but can reduce concurrency.

Higher isolation avoids anomalies (dirty read, non-repeatable read, phantom read) but can cause more locking or aborts. Use read committed or repeatable read unless you have a specific need for serializable.

Use a transaction when multiple writes must succeed or fail together: e.g. create order + deduct inventory + create payment record. Use a single transaction so a failure in any step rolls back all. For read-only operations you usually do not need a transaction unless you need repeatable read or a consistent snapshot.

Keep transactions short: do not hold a transaction open while calling external APIs or doing heavy computation. Acquire locks late and release early.

When data lives in multiple databases or services, a single ACID transaction across them is hard. Two-phase commit (2PC) exists but is complex and can block. In practice, many systems use sagas: a sequence of local transactions with compensating actions (e.g. if "charge payment" succeeds but "ship order" fails, run "refund payment"). Design for eventual consistency and idempotency so retries are safe.