Why does an atomic transaction accept all its changes or none?

A transaction groups related database changes into one operation. Atomic means all or nothing: its completed effects are accepted together, or the grouped changes are canceled. The transaction boundary matters because an individual internal step is not necessarily a valid result for the application.

Two fictional inventory records begin with A holding eight units and B holding three. A transfer of two units requires subtracting two from A and adding two to B. A completed transfer leaves A at six and B at five. The total remains eleven because the intended updates subtract and add the same amount.

The first internal update might occur before the second. If an interruption happens after the debit, the system must not accept A at six and B at three as the final transfer. Rollback cancels the grouped changes, returning the visible records to eight and three. Commit instead accepts both successfully completed updates together.

The toy also checks that A has enough units before allowing the transfer. That rule is separate from atomicity. An all-or-nothing operation could still contain the wrong calculations if its application rules were wrong. Atomicity makes the group indivisible; it does not supply every other correctness condition.

This transaction covers only the stated database changes. Sending an unrelated message or changing another external system would require additional coordination. Concurrent transactions and persistent storage raise other guarantees. Keeping those distinctions explicit makes the all-or-nothing promise precise rather than treating it as a promise that every part of a larger workflow is automatically reliable.