Why doesn't money vanish when two bank transfers happen at once?

Money doesn't vanish because the database treats a transfer as one indivisible unit of work, called a transaction, and follows four rules known as ACID. A bank transfer has two steps: take money from one account, add it to another. If the machine crashed between them, or a second transfer sneaked in halfway, the numbers could end up wrong. ACID is the promise that this never happens.

Atomicity says a transaction either succeeds completely or fails completely. If any step fails, the whole thing fails and the database is left unchanged, so the money can't leave account A without arriving in account B. Consistency says a transaction can only take the database from one valid state to another, respecting its rules. Durability says that once a transaction is committed, it stays committed even through a crash or power cut. To keep that promise, many databases write the change into a log on safe storage first, before touching the data itself.

The rule that covers two transfers at once is isolation. At its strictest, running transactions concurrently must leave the database in the same state as if they had run one after another. Without it you can get problems such as a dirty read, where one transaction reads a row that another has changed but not yet committed, and might yet cancel.

Theo Härder and Andreas Reuter coined the acronym in 1983, building on Jim Gray's earlier work. The idea was already running in IBM's IMS in 1973.