“We put everything in a transaction” is a useful answer about reliability, but it leaves something important unspecified. What counts as everything? Database updates, a request to a payment provider, or the email the customer has already received? The boundary determines which failures the system can undo and which require somebody to repair the business process.
ACID stands for atomicity, consistency, isolation and durability. For an executive, the useful starting point is the promise being made: which changes must succeed as one operation, and does the implementation cover all of them?
Two entries that must stay together
Consider an illustrative internal accounting system that reallocates budget between projects. It reduces one project's allowance, increases another's and records the reason for the transfer. All three changes belong to one transactional database. If the application stops after the first update, the company does not want a half-completed transfer with some of its budget missing.
The changes belong in one transaction. On success, the database commits them together. If the transaction is rolled back before commit, its changes are discarded. Other operations should not see a committed half-transfer. That is atomicity: the complete result or none of it. It is not a promise that any action involving money in any connected system can be reversed.
An external bank transfer is deliberately outside this example. If the application has separately instructed a bank to move funds, rolling back its own database does not instruct the bank to forget the payment. Calling both actions “the payment” can conceal a very consequential boundary.
The database cannot enforce a rule it was never given
Consistency concerns preserving defined data rules through correctly designed transactions. The database does not discover that a transfer must not exceed an available allowance or that an employee cannot approve their own request. Some rules can be expressed as database constraints: a unique operation number, mandatory values or valid relationships between records. Others belong in application logic.
A transaction can faithfully preserve the result of an incorrect calculation. Asking whether a database supports ACID is therefore not a substitute for specifying the rule. Our budget transfer must conserve the overall amount, prevent a prohibited negative allowance and distinguish a retry from a new instruction. Each requirement needs an actual safeguard.
Isolation addresses concurrent work. Two transfers can independently inspect the same available allowance and both conclude that enough remains. Atomicity of each transfer does not automatically make their combined outcome valid. An appropriate isolation level, conditional update or lock must protect the shared rule.
Stronger isolation does not necessarily put every request into one physical queue. Some implementations detect a dangerous combination of concurrent transactions and abort one. The application must then rerun the rejected transaction, including its decisions, or report that the action could not be completed.
What does a successful commit acknowledge?
Durability is the promise that a committed result survives the failures covered by the system's guarantees. The acknowledgement matters. PostgreSQL's asynchronous commit option, for example, can return success before the relevant log records have reached durable storage. A crash in that interval may lose recent acknowledged changes. That is a different guarantee, not merely a faster implementation of the same service.
Durability also does not protect against every kind of loss. A sufficiently privileged deletion is an operation the database may preserve quite reliably. Losing an entire site needs a different recovery plan. Replication, backups and tested restores address additional risks. ACID alone does not justify a promise that no information can ever disappear.
The transaction committed, but the answer disappeared
Another awkward failure occurs when commit succeeds and the connection breaks before the application receives the result. The database knows what happened; the client does not. A connection error is not proof that the transfer was rolled back.
Issuing a new transfer under a new identifier would be dangerous. The application needs a stable operation identity, status lookup and safe handling of retries. A transaction protects one execution. It does not automatically recognise that two requests represent the same user intention.
If another system must be notified after the transfer, the intention to publish can be stored in the same transaction as the budget changes. A separate process then delivers the message. A Transactional Outbox closes the gap between committing the fact and arranging future delivery, while the recipient still has to tolerate duplicates.
Keep the boundary workable
Holding a transaction open while a person studies a document or an external service responds is usually a poor design. Connections, locks and other resources may remain occupied throughout the wait. Preparatory work and human approval can happen earlier, followed by a short transaction that checks current conditions before committing. An approval based on old information must not silently override newer facts.
Distributed transactions exist, but they require participating systems, an agreed protocol and deliberate failure handling. Wrapping several HTTP calls between BEGIN and COMMIT does not create one. If independent participants have already taken action, recovery may involve compensating operations. A refund or correction does not provide the same all-or-nothing boundary as a local transaction.
Acceptance testing should distinguish three cases: stop the process before commit, lose the response after commit, and run two competing instructions against the same allowance. Each needs different evidence. The first should leave no half-transfer, the second should not create another transfer, and the third should preserve the budget rule. Those are concrete behaviours the company can inspect and promise.