State and recovery
A change that either happens completely or does not happen at all — and the argument is always about where it ends.
Also called Atomic operation · Транзакция
The property is easy to state and expensive to get wrong: no observer ever sees half of it. Money left one account and did not arrive in the other; stock was reserved and the order was never created; the invoice exists and the payment against it does not. Each is a transaction boundary drawn in the wrong place, and each produces a class of support ticket nobody can reproduce.
Where it ends is a business decision that gets made by accident. A booking is a payment, a seat, a confirmation and an accounting entry. If all four are inside one boundary the system is slow and correct. If the payment is inside and the confirmation is outside, the customer is charged and told nothing — which is the failure most often discovered by the customer.
The consequence of drawing the boundary casually is that the reconciliation becomes somebody's job forever. Every operations team that spends its mornings comparing two systems is paying, daily, for a boundary decision made once in an afternoon.
A database transaction covers one database. The moment a payment gateway, a warehouse API or an accounting service is inside the same logical operation, atomicity has to be built rather than assumed — usually as an idempotent retry with a recorded outcome. Code that reads as though four systems commit together is code that will one day leave three of them agreeing and one not.
The definitions are the easy part. Whether the figure on your dashboard was computed this way is a different question, and usually the more expensive one.