ACID is an acronym that represents a set of four important rules used in databases and in system development.
Do I still consider it relevant to understand these concepts in the post-LLM era? Yep. I consider this the first concept someone should know to begin studying System Design.
Concept
The 4 ACID rules are:
- Atomicity
- Consistency
- Isolation
- Durability
Atomicity
Atomicity is the rule responsible for preventing half-completed operations. Whenever I read texts and explanations about this subject, I found financial examples. But the application of this rule is not limited to financial applications; quite the contrary.
Example
I remember a startup I worked at years ago where, when you created a user, there were several other things tied to the business rule besides inserting the user into the database, such as creating an organization, generating a Web3 wallet for the user, and defining the user’s basic settings.
User
Organization
Wallet
UserSettings
As soon as I joined the project, I realized that you would frequently create a user, something would be missing, and then you would not be able to authenticate with that user in the system.
The endpoint that created the user was quite large; it did a lot, and sometimes you didn’t even know what had failed.
But what matters, for our analysis here, is understanding that we cannot create a user but not create their wallet. We also cannot create a user in the database that doesn’t have an organization linked to it. All 4 steps are part of a single transaction: the user creation in the system.
Solution
In this case, everything that needed to be generated during the process would be generated first (the wallet, for example), and then, when inserting it into the database, we would use a similar transaction:
generate wallet
↓
BEGIN
↓
INSERT User
INSERT Wallet
INSERT Membership
INSERT Settings
↓
COMMIT
Why does this need to be a single transaction? Because if any of these operations failed, I don’t want the user to be partially created. This is exactly the concept of atomicity.
Atomicity and LLMs
It would be naive of you – as a developer – to believe that Claude Code or Codex will always write code that doesn’t fail. In this case, we need human involvement, and I have a few points to suggest.
Skill.md and AGENTS.md
Interestingly, you turn this knowledge into an operational and checkable rule. For that, writing database instructions in these files is relevant. And it’s in these instructions that you should include the knowledge of Atomicity. An example of what to add in this file could be:
## Database Transactions
When implementing a use case that performs multiple database writes:
1. Identify whether the writes form a single business operation.
2. If a partial execution would leave the database in an invalid or
undesirable business state, execute the writes inside a database
transaction.
3. Use the transaction-scoped database handle for every operation that
belongs to the transaction.
4. Do not introduce transactions merely because there are multiple SQL
statements; evaluate the business boundary first.
5. Do not assume that external side effects such as Kafka messages,
HTTP calls, emails, or third-party APIs participate in the database
transaction.
6. For database + external-event consistency, follow the project's
Outbox/Idempotency pattern.
7. Add or update tests covering rollback when a later operation fails.
But one thing you need to keep in mind is: textual instructions are a layer of defense, not a guarantee.
Tests as guardrails
Having knowledge of the business rule and understanding the importance of keeping user creation consistent (yes, you still need to work… my friend), I would write rollback tests, for example. The test would call the user creation flow and force an error during wallet creation. This test should return a rollback as executed, and we should validate that the user wasn’t created, nor assigned to an organization, nor given the default settings.
This test would then become an executable proof of the atomicity rule in user creation.
Notes
- What if the wallet creation were done in an external service and not locally? Then the solution couldn’t be just traditional SQL ACID.
- Juniors continue to write junior-level code even when using LLMs.
