What problem are we solving?
A business operation often contains several changes that should be treated as one action. For example, a system should not successfully reduce inventory and then fail to record the transaction that caused it.
If only part of the change is applied, the system may reach a technically possible state that makes no business sense.
How do ACID transactions work?
ACID describes four properties: atomicity, consistency, isolation, and durability. In practical terms, a group of changes either commits as one unit or rolls back, while concurrent operations should not arbitrarily violate the data rules.
Inside one database, this is usually a natural and powerful tool. The more systems we try to include in one shared transaction, the harder coordination, recovery, and availability become.
What does the business get?
The main benefit is protection of critical invariants. Where an error means money, duplicate sale, incorrect balance, or legally invalid state, a strict transaction boundary significantly reduces risk.
A transaction also simplifies reasoning: the business can treat several technical writes as one logical operation.
What does the team get?
The team gets a straightforward mechanism for local integrity: commit, rollback, isolation levels, and a clear model for concurrent changes.
At the same time, the team must manage transaction duration, locks, deadlocks, and isolation choices. A transaction that is too wide can itself become a source of latency and outages.
What does the customer get?
The customer is less likely to see states such as “money was charged but the order does not exist” or “the last item was sold twice.”
They do not experience this as ACID. They experience it as predictability: the operation either happened or it did not.
What do we pay for it?
Strict coordination reduces parallelism and can increase latency. The stronger the isolation, the more operations may need to wait for each other.
Trying to run one transaction across several services is especially expensive: networks fail, participants respond at different speeds, and coordination starts to affect availability of the entire process.
When is it unnecessary?
Not every business process needs immediate global consistency. Notifications, analytics, search indexes, and many cross-service workflows are often cheaper and sufficiently reliable with eventual consistency.
If compensation is acceptable, a Saga may be a better fit than a distributed transaction.
What should we ask before deciding?
- Which business invariants must never be violated, even temporarily?
- Can the transaction stay inside one database or one service?
- What happens when concurrent operations change the same data?
- Can compensation replace an immediate rollback?
- Which isolation level is actually required rather than simply feeling safer?
In the end
ACID is not a universal marker of “correct architecture.” It is a strong guarantee for boundaries where the business truly cannot accept an intermediate invalid state.
It is usually better to make a small transaction boundary extremely reliable than to force an entire distributed business process to behave like one database.