ACID transactions

An ACID transaction is a group of database operations that behaves as one unit. ACID names four guarantees: atomicity (all of the changes apply or none do), consistency (each transaction moves the data from one valid state to another and respects its constraints), isolation (concurrent transactions do not see each other's half-finished work) and durability (once a commit is acknowledged, it survives a crash).

How it works

The database writes each change to a write-ahead log before applying it, so after a crash it can redo committed work and undo uncommitted work. Locks or multi-version concurrency control (MVCC) provide isolation, and the isolation level, such as read committed or serializable, decides which anomalies concurrent transactions can still see.

For example, to move 100 from account A (balance 500) to account B (balance 200), run BEGIN; UPDATE accounts SET balance = balance - 100 WHERE id = 'A'; UPDATE accounts SET balance = balance + 100 WHERE id = 'B'; COMMIT;. Either both updates commit, leaving A at 400 and B at 300, or the transaction rolls back and A stays at 500 and B at 200. The total is 700 either way. In the One2N Go bootcamp's Redis exercise, MULTI queues commands and EXEC runs them as one block. Real Redis runs that block without interleaving other clients, but it does not roll back: if one queued command fails at run time, the others still apply.

Why it matters in production

Without atomicity, a crash between the two updates above loses 100. Without enough isolation, two concurrent withdrawals can both read a balance of 500 and both succeed, a race condition. Know your database's default isolation level (read committed in PostgreSQL, repeatable read in MySQL InnoDB), keep transactions short because they hold locks, and remember that ACID covers one database. A change that spans a database and a message queue needs a pattern such as the outbox, plus idempotent consumers.