ACID Properties in Database transactions
Tags: webdev, backenddevelopment, database, beginners
Published: 2024-06-14 05:34:56

As a backend developer you must take into consideration the properties that comes with the database you are using for your project. When using  databases, there are a set of properties or principles you are to take note of and one of them is the **ACID** properties. These properties ensures that nothing goes wrong for any database transaction. ACID is an acronym that stands for **Atomicity**, **Consistency** , **Isolation** and then **Durability**. Lets dive into what each of them means when it comes to database transactions.

---
                         
#Atomicity


![Image depicting Atomicity Property](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vehsnkm1lz1edb8cg56u.jpg)
This property ensures that all operations within a transaction are completed, if not, the transaction is terminated and then no operations will be committed. What this means is that, a transaction is irreducible and indivisible which ensures that no partial transactions occur. An example of the atomicity property in ACID properties is with a simple bank transfer scenario. Suppose you want to transfer $100 from Account A to Account B. The transaction will obviously involve two main operations:
a. Debit $100 from Account A
b. Credit $100 to Account B
Well, atomicity ensures that the two operations are treated as a single indivisible unit. This means that either both operations are successfully completed or neither of them is. So for a successful transaction, Account A's balance is reduced by $100 and then Account B's balance is increased by $100, in this case both operations completed successfully hence the transaction will be committed. For a failure scenario where for instance there is a power failure when the debit from Account A was effected, without atomicity, Account A would be debited and Account B would not be credited hence leading to an inconsistent state. Without atomicity the the transaction will not be completed in its entirety, hence it is rolled back and therefore returns to the original state.

---

#Consistency

![Image depicting the Consistency proerty](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lbo3mmba5z4s4oygt4t6.jpg)
This  property guarantees that a transaction can only bring the database from one valid state to another hence maintaining database invariants. This means that any data that is written to the database must be valid according to constraints, rules, triggers etc.

A very simple example for this property can be illustrated with a bank account. Suppose the rule to that account is that it cannot have a negative balance.
**Scenario**:
a. **Initial State**: _Account A has a balance of $500_
b. **Transaction**: _Withdraw $700 from Account A_  
Now by allowing the transaction to go through the system needs to ensure that the account balance will not violate the constraint that is ,"_cannot have a negative balance_" . When the check is done the transaction is aborted and the withdrawal does not go through.

---
#Isolation

![Image depicting the Isolation property](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bnx3tscp44aml5nb5i5a.jpg)
For this property it ensures  that the concurrent execution of transactions results in a state that would be obtained if transactions were executed serially, one after another. It makes sure that transactions do not interfere with each other.
**Scenario**: 
Lets see how the transaction will pun out when there is the Isolation property in place:
**T1**: _Read balance of Account X (balance = $1000)._
**T1**: _Withdraw $100 from Account X(new balance = $900)._
**T1**: _Write new balance to Account X (balance = $900)._

**T2**: _Read balance of Account X (balance = $900)._
**T2**: _Deposit $200 to Account X (new balance = $1100)._
**T2**: _Write new balance to Account X (balance = $1100)._

In this scenario, transaction 2 waits until transaction 1 is complete, making sure that the operations do not interfere with each other. The final balance in Account X is correctly updated to $1100.
Isolation ensures that concurrent transactions are performed in such a way that they appear to be executed sequentially, preserving the integrity and correctness of the database.

---

#Durability

![Image depicting the durability property](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nf5cgxht6i9mzzytuw2s.JPG)
This property ensures that once a transaction has been effected or committed, it remains so, even in the event of a system failure or crash. A typical instance is the use of transaction logs and backups to ensure that the committed data is never lost.
**Scenario**: _Deposit Money into an Account_

**Initial State**: Account A has a balance of $1000.
**Transaction**: Deposit $200 into Account A.
Process:
**Step 1**: _Commence the transaction._
**Step 2**: _Read the current balance of Account A ($1000)._
**Step 3**: _Deposit $200 into Account A(new balance = $1200)._
**Step 4**: _Write the new balance ($1200) to Account A._
**Step 5**: _Commit the transaction.(Transaction log showing as complete)_
Lets see how the transaction puns out when durability is in place;
After the transaction is effected, durability ensures that the changes made to the database (the new balance of $1200) will persist, even if there is a system failure immediately after the transaction is committed. In a case where there is a system failure for instance, after the committing the system experiences a power failure and crashes, despite the crash, when the system is restarted, the account balance will still be as is when the transaction was committed.

That's a wrap **Devs** I hope this post would help you gain some knowledge on the various parts of the ACID property or principle. Don't forget to like, comment and share. Follow me for more exciting and interesting posts here on **DEV** Community.