#16: ACID
Welcome back to The Coder Cafe! This week, the theme will be database fundamentals, and we will start by exploring the concept of ACID.
The ACID properties—Atomicity, Consistency, Isolation, and Durability—are key database concepts. Understanding these four properties is critical for anyone working with databases. Let’s break them down.
Atomicity
Definition: All the operations of a transaction must succeed, or none will.
In simpler terms: All or nothing. If one part of a transaction fails, the entire transaction is rolled back, leaving the database unchanged. For example, imagine a bank transfer where money is deducted from one account and added to another. If either step fails, the entire transaction is rolled back, and neither account is updated.
Note that the concept of atomicity can also extend beyond databases to distributed systems. For instance, we may want to design a process that both writes to a database and publishes a message to Kafka. Yet, we want to guarantee that if one operation fails, the other operations will be reverted. In this case, we can say the process is atomic, as it will be all or nothing as well. Yet, it becomes a property of the entire system, not just the database.
Consistency
Definition: The database must transition from one valid state to another.
The definition can be divided into two parts:
Transaction-level consistency: At the transaction level, the database must ensure that only legal transactions are accepted. This means that transactions must adhere to the database’s predefined integrity rules, such as foreign key constraints and data type requirements. These rules ensure that each transaction maintains the structural integrity of the database.
Application-level consistency: Yet, the concept of a valid state is not necessarily a property of the database itself. For instance, if we want to guarantee that the sum of customer balances should always be positive, it’s an invariant that must hold true from an application standpoint. This isn’t a rule that a database alone can enforce.
It’s also important to distinguish the concept of consistency in ACID and eventual consistency:
Eventual consistency refers to a consistency model12 in distributed systems. Consistency in this context refers to convergence—what are the guarantees when data is replicated across different nodes?
The C in ACID isn’t about data replication but more about data integrity.
Isolation
Definition: A transaction is not affected by another ongoing transaction.
Isolation ensures that the outcome of a transaction is not affected by some possible interference from other transactions, such as transactions observing partial results from one that hasn’t been committed yet.
In ACID, isolation refers to the concept of serializability3, meaning transactions should appear to be executed in a serial order, even if they are run concurrently.
Durability
Definition: Once a transaction is committed, its changes must be permanent and will not be lost.
Durability ensures that once a transaction is committed, its data is guaranteed to be saved, even in the case of a system crash. Techniques like Write-Ahead Logging (WAL) or other forms of persistent storage are typically used to guarantee this, making it possible to recover committed data after a failure.
Conclusion
While ACID properties are fundamental for traditional relational databases, many systems sometimes relax these guarantees to improve scalability and performance.
Tomorrow, we will discuss another fundamental database concept: the CAP theorem.
One of the weakest consistency models.
We will explore the concept of models in a future week as it’s a crucial topic in databases.
Another topic that we will explore in a future issue.