DEV Community

Cover image for ACID Properties in Database transactions
Richard Boachie
Richard Boachie

Posted on

ACID Properties in Database transactions

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
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
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
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
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.

Top comments (0)