Transactions: The Problem They Actually Solve

The starting point

A transaction is often introduced with the phrase all-or-nothing, but that is only the beginning. The deeper idea is that several operations should behave as one unit from the perspective of consistency. If a workflow creates an order, reserves inventory, and records payment state, allowing only the first two operations to succeed can produce data that is difficult to repair. Transactions give the database a mechanism for defining the boundary of that unit.

Atomicity is about partial failure

Imagine inserting a parent row and then several child rows. If the parent succeeds but one child insert fails because of a constraint, the application may be left with incomplete state. A transaction allows the entire set of changes to be rolled back so the database returns to its previous consistent state.

This does not mean every function should automatically run inside a transaction. A transaction has a scope, and the scope should correspond to a business operation whose intermediate states should not become visible as committed data.

Transactions do not replace good design

A transaction cannot fix an incorrect data model. It can guarantee that the operations you chose happen atomically, but if the model permits contradictory states, the transaction will faithfully commit those contradictions. Constraints and transaction boundaries work together.

Long-running transactions can also create contention and operational problems. The goal is not to keep a transaction open as long as possible; it is to keep the consistency boundary large enough to protect the operation and small enough to remain practical.