Loading content
ACID is a foundational principle for transactions in database systems; it groups Atomicity, Consistency, Isolation and Durability to ensure integrity and recoverability. It defines expectations for failures, concurrency and persistence, and highlights typical design and performance trade-offs in system architecture.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
ACID groups four properties (Atomicity, Consistency, Isolation, Durability) for database transactions, aiming to keep data integrity and to ensure predictable behavior under failures, concurrency, and crashes.
The underlying problem was how to treat a set of related data changes as a single, valid unit despite errors, power failures, and other mishaps. The acronym ACID was coined in 1983 by Andreas Reuter and Theo Härder; it builds on earlier work by Jim Gray, who named Atomicity, Consistency, and Durability when characterizing the transaction concept (not including Isolation at that time).
Think of a transaction as a closed work block. Multiple steps execute first in a protected intermediate phase. If everything succeeds and rules are satisfied, the system finishes the block as a unit (commit). If a failure occurs or a rule cannot be satisfied, the system undoes what already happened (rollback), so no one observes a “half-completed” state. Concurrent transactions do not see the intermediate changes; they observe only the final state after the commit. After commit returns success, the effects must remain present even after a crash—so the database records the completion reliably before reporting the transaction as done.
A transaction behaves like an indivisible unit: either all steps take effect, or none do—preventing partial results.
The transaction moves the database from one consistent state to another by preserving defined invariants/rules.
Concurrent transactions are prevented from exposing each other’s intermediate work, so observed outcomes match a serial execution.
Once committed, the transaction’s effects remain in place permanently, even if a system failure happens shortly after.
ACID is most useful when you need to reason about correctness under real failure modes and concurrent access—common in order, booking, or financial-style application logic. The prerequisite is a database system that supports transactional semantics with these guarantees. The trade-off is that stronger guarantees can add operational and performance costs: constraint checking, isolation behavior, and reliable logging may increase latency/throughput impact, and failures can cause the whole transaction to be canceled rather than partially progressing.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.