What is a database transaction

A transfer is a subtraction and an addition, as a pair

In the last lesson we split tables so that each fact lives in only one place. Even so, some jobs cannot be finished by changing just one place. A bank transfer is one of them: money has to come off your balance, and the same amount has to go onto the receiver's balance.
These two steps are a pair that cannot be pulled apart. If only one of them happens, money either vanishes or appears from nowhere. Let's try the two changes separately below.

Tap the subtraction and the addition separately. Press only one and the total of the two balances changes: money either vanishes or appears from nowhere.

Press only the subtraction and your money disappears; press only the addition and money appears out of nowhere. Either way, the total of the two balances is no longer what it was at the start. A transfer only moves money, so the total should stay the same.
The danger lies in the short gap between the subtraction and the addition. If the power goes out or the program stops in that gap, the ledger is left out of balance. So we need a way to tie the two changes together.

All of it happens, or none of it does

The method is simple. Bundle the subtraction and the addition into one unit, and call that unit a transaction. Every change inside it is kept as provisional.
Once everything is ready, the transaction is confirmed and applied for real all at once; if even one part fails, the whole thing is cancelled. Confirming is called a commit, and cancelling and undoing is called a rollback. This way, a half-applied state never comes into being, and no one else ever sees the in-between state. This property is called atomicity: the transaction is one unit that cannot be split any further.

Put the two changes into one bundle. You can commit only when both are in, and cancelling removes both.

Commit, and the two balances change together so the total stays the same; cancel, and both changes vanish cleanly. Either way, the ledger stays in balance. Simply handling the changes as a bundle has closed the dangerous gap.
But what if the power really does go out partway through the work inside the bundle? What happens to the provisional changes?

Cut off, it rolls the whole thing back

Before changing anything, a database first writes down what it is about to change, and how, in a record called a log. It also keeps the information needed to return to the state before the work began.
So even if the power goes out partway through, when the database starts up again it can read the log and find any bundle that did not finish. Rather than leave half of it in place, it rolls that bundle all the way back to the state before it began. A bundle that was already committed, on the other hand, survives the power cut intact. This property, that committed results are never lost, is called durability.

Advance one step, then tap the power cut. Instead of leaving half done, it rolls all the way back to the starting state noted aside.

The power was cut, yet the ledger is unharmed. Instead of a messy state with only the subtraction applied, it went cleanly back to the start. That is a rollback.
Since a failure leaves no trace, you can simply start again from the beginning. Before the transfer and after it, the ledger's rules, such as the rule that the total of the two balances stays the same, are kept. This is called consistency. But what happens when several people try to change the same balance at the same time?

Even arriving at once, handled one at a time

Think back to the race condition from the operating systems area: when two parties touched the same resource at once, the result got tangled. A balance is no different.
If two people read the same balance at the same moment and each writes back the value they calculated, the one who writes last overwrites the other's result, and one person's change disappears entirely. This is called a lost update. So a database uses mechanisms such as locks to handle bundles that change the same row one at a time, in turn.

Send both people at once. Left as is, the later writer overwrites and one change is lost; held in turn, both are added.

Left as is, one person's change was lost; handled in turn, both were applied. Even when requests arrive together, they wait in line for a moment, and the next bundle is taken only after the previous one has finished.
This property, keeping bundles that run at the same time from seeing each other's in-between states, is called isolation. Lining everything up strictly makes things slow, though, so real databases let you choose how strictly bundles are kept apart.

Summary

To sum up: changes that must happen together are bundled into one unit so that all of them happen or none of them do. If the work is cut off partway, the database reads the log and rolls everything back to the start, and committed results survive even a power cut.
When several bundles try to change the same place at once, they are lined up in turn so that nothing is overwritten. Atomicity, consistency, isolation, and durability, known by their initials as ACID: these four promises are what a transaction is.

Tap the key points in order to review. (a transfer is a pair → all or nothing → roll back on failure → no tangling at once)

Now you know the promises that let data be changed safely. The gap where money vanished, the accident where a power cut left half a transfer behind, the confusion of simultaneous changes overwriting each other: the idea of a single bundle guards against all of them.
After changing data safely comes reading it quickly. The next lesson, on caching, covers how to keep a copy close at hand instead of going all the way to the database for the same data again and again.