Backend & Node.js · APIs, data and failure
What does ACID mean and how do you use transactions correctly?
Short answer
ACID means atomicity, consistency, isolation and durability. A transaction groups operations so they commit together or roll back together, while isolation controls what concurrent transactions can observe.
Atomicity means all or nothing. Consistency means constraints and invariants hold at commit. Isolation means concurrent transactions do not corrupt each other. Durability means committed data survives a crash. The database provides the mechanics, but the application must still define a correct transaction boundary.
BEGIN;
UPDATE accounts
SET balance = balance - 100
WHERE id = 1 AND balance >= 100;
UPDATE accounts
SET balance = balance + 100
WHERE id = 2;
COMMIT;Practical rules
- Keep transactions short to reduce lock time and contention
- Never do network calls inside a transaction; a slow payment API can hold locks
- Do not interleave user think time with an open transaction
- Use the database constraint as the source of truth, not a prior application check
- Handle serialization failures with a bounded retry
- Choose the isolation level deliberately rather than relying on a default
A common race is read, check, then write. Two requests can both pass the check before either writes. A unique constraint, a conditional update or a row lock closes the gap. Transactions do not make arbitrary application logic safe unless the read and write are protected by the same isolation guarantee.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What is the difference between atomicity and consistency?
- 2Why should you avoid network calls inside a transaction?
- 3How do you prevent a check-then-write race?
- 4What happens when a transaction is rolled back?
Say it in the interview
ACID gives me all-or-nothing execution, constraint enforcement, isolation from concurrent work and durability after commit. I keep transactions short, avoid network calls inside them and rely on constraints or conditional updates instead of check-then-write logic. Isolation level is a deliberate choice, and serialization failures should be retried with a bound. Transactions protect the boundary I define, not business logic that runs outside it.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Backend & Node.js mock interview and get scored feedback on depth, clarity and confidence.