Core Idea
ACID is a set of properties (Atomicity, Consistency, Isolation, Durability) that guarantee reliable processing of database transactions by ensuring all operations either complete fully or fail completely.
Definition
ACID guarantees reliable transaction processing in databases. All operations within a transaction either complete fully or fail completely, leaving the database in a valid state despite errors, power failures, or system mishaps.
Key Characteristics
- Atomicity: Each transaction is all-or-nothing—if any step fails, all changes revert, preventing corruption from incomplete operations
- Consistency: Transactions move the database between valid states only—referential integrity, foreign key constraints, and business rules are always satisfied. Distinct from Consistency in the CAP-Theorem (replica agreement)
- Isolation: Concurrent transactions execute as if sequential—incomplete transaction effects are invisible to others. Isolation levels (Read Uncommitted → Serializable) trade performance for stronger guarantees
- Durability: Committed transactions survive power outages and crashes—achieved through write-ahead logging and non-volatile storage
- Distributed trade-off: Maintaining ACID across multiple nodes conflicts with the CAP-Theorem—strong consistency reduces availability during network partitions, producing BASE (Basically Available, Soft state, Eventual consistency) as an alternative
Why It Matters
ACID is the foundation for systems requiring strong consistency—financial transactions, inventory management, and any domain where partial failures are unacceptable. Relational databases (PostgreSQL, MySQL, Oracle) provide ACID compliance by default. In distributed architectures, ACID across service boundaries requires Distributed-Transactions (2PC), which reduces availability and creates tight coupling. This is why microservices often favor the Saga-Pattern with Eventual-Consistency for cross-service workflows. Architects must evaluate per-domain whether ACID or BASE best fits business requirements.
Related Concepts
- Coupling: ACID transactions create temporal coupling between operations
- Bounded-Context: Domain boundaries influence transaction scope decisions
- Architecture-Quantum: ACID scope often defines deployment unit boundaries
- Contract: Transaction boundaries define consistency contracts
- Orchestration: Centralized coordination can enforce ACID-like properties
- Monolithic-vs-Distributed-Architectures: Architecture choice fundamentally impacts ACID feasibility
- Trade-Offs-and-Least-Worst-Architecture: ACID vs availability is a fundamental trade-off
Sources
-
Databricks (2025). “ACID Transactions in Databases.” Databricks Glossary. Available: https://www.databricks.com/glossary/acid-transactions
-
Wikipedia Contributors (2025). “ACID.” Wikipedia. Available: https://en.wikipedia.org/wiki/ACID
-
AWS (2025). “ACID vs BASE Databases - Difference Between Databases.” Amazon Web Services. Available: https://aws.amazon.com/compare/the-difference-between-acid-and-base-database/
-
Neo4j (2025). “Data Consistency Models: ACID vs. BASE Explained.” Neo4j Blog. Available: https://neo4j.com/blog/graph-database/acid-vs-base-consistency-models-explained/
-
Ford, Neal, Mark Richards, Pramod Sadalage, and Zhamak Dehghani (2022). Software Architecture: The Hard Parts - Modern Trade-Off Analyses for Distributed Architectures. O’Reilly Media. ISBN: 9781492086895.
Note
This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.