ACID is often discussed as a database feature.
Sometimes as an outdated one.
That framing misses something fundamental.
ACID was never primarily about storage engines. It was about correctness: how a system preserves meaning while work is performed. Early transactional theory, notably articulated by Jim Gray, treated transactions as units of state transformation that preserve invariants. In other words: something happens, and the system remains valid.
Stripped of implementation detail, ACID says something almost trivial:
A piece of business logic either succeeds or fails.
Nothing more.
This article proposes a simple idea:
The ease with which you can express ACID semantics is a useful litmus test for system simplicity.
Not simplicity as “few services” or “small codebase”, but simplicity as clear, local, and comprehensible business behavior.
ACID Without Mysticism
Before discussing architecture, it helps to de-dramatize ACID.
At a semantic level:
Atomicity → The operation completes or it does not.
Consistency → Business rules remain true.
Isolation → Concurrent operations do not observe nonsense.
Durability → Completed decisions are not forgotten.
These are not database tricks.
They are descriptions of how real-world business actions are expected to behave.
When someone places an order, the business does not conceptually accept “half an order”.
When money is transferred, the organization does not consider “eventually maybe transferred” a meaningful state.
ACID is simply the smallest vocabulary that describes this expectation.
Cheap ACID Boundaries
If a piece of business logic:
Executes in one place
Operates on a coherent model
Owns its own invariants
then drawing an ACID boundary is almost boring.
Begin work.
Perform logic.
Commit or rollback.
This is what we can call a cheap ACID boundary.
Cheap not in licensing cost.
Cheap in reasoning cost.
There is one execution context.
One authority over state.
One moment where success or failure is decided.
In such a setup, a relational database is a natural storage fit—not because it “creates correctness”, but because it can mechanically record an already clear decision.
The database is not the source of rigor.
The model is.
Essential Complexity and Visibility
Fred Brooks famously distinguished between:
Essential complexity – inherent to the problem.
Accidental complexity – introduced by the solution.
Business rules, invariants, and transactional boundaries are essential complexity. They exist whether we like it or not.
When essential complexity is:
Explicit
Local
Visible
a business operation can be understood as a single unit of intent.
Once that unit exists, ACID semantics follow naturally.
Not as an architectural goal.
Not as a framework feature.
But as a consequence.
When ACID Becomes “Hard”
ACID usually becomes “hard” only after something else happened first.
Typically:
Business rules are split across services
State ownership is divided
Invariants are enforced in multiple places
Now a single business operation no longer has a single center.
At that point:
Atomicity becomes choreography
Consistency becomes convention
Isolation becomes probabilistic
Durability becomes replicated folklore
ACID did not become complex on its own.
The business concept was fragmented.
The cost increase is secondary.
The Litmus Test
For any business operation, ask:
Where is the moment that decides success or failure?
Where are the invariants enforced?
Who owns the truth of this operation?
If these questions have clear, local answers, ACID will be easy.
If the answers involve:
Multiple services
Multiple databases
Multiple asynchronous hops
then ACID will be expensive.
Not because ACID is outdated.
But because the system no longer has a simple place where “this either worked or it didn’t” can be stated.
That is the litmus test.
Relational Databases and the Boring Path
Relational databases often appear in this discussion, and that is not accidental.
They provide:
Transactions
Constraints
Rollback
Which map cleanly onto cohesive business operations.
This does not make them universally superior.
It makes them unsurprising.
When your model is simple, simple tools fit.
When your model is fragmented, no tool will feel simple.
ACID as a Complexity Indicator
This perspective does not attempt to accommodate every architectural fashion.
It does not try to explain how ACID can be stretched, simulated, or approximated in increasingly fragmented systems.
Instead, it treats ACID as a simple indicator:
When a business operation can no longer be expressed as a straightforward success-or-failure unit, the system has already become more complex than it needs to be.
That complexity may be intentional.
It may be justified by extreme scaling constraints or unusual operational environments.
But it is still complexity.
ACID is useful precisely because it makes this visible.
Not as a rule to obey.
Not as a feature to retrofit.
But as a signal:
If drawing a cheap ACID boundary feels unnatural, forced, or impossible, that is not a limitation of ACID.
It is a sign that the application’s structure has drifted away from the simplest expression of its business intent.
ACID as a Mirror
ACID does not impose discipline.
It reflects discipline.
When ACID feels heavy, awkward, or impossible, that is a signal worth listening to.
Not about databases.
Not about frameworks.
But about whether the essential complexity of the domain is still visible, coherent, and whole.
In that sense, ACID is less a technology choice than a mirror.
And mirrors are useful precisely because they do not lie.
Top comments (0)