ACID Transactions In Databases Explained

Before explaining what ACID means, let's first understand what a transaction is. In the context of databases,

Not to worry, my goal for this article is to explain all this to you in simple terms. If you are a backend developer especially, then understanding this concept is supercritical.

A classic example of a transaction is when you transfer money from your bank account to another bank account. Either the money has left your account or not. There is no in-between state.

Imagine you were transferring money to someone and your account got deducted but the person you were sending the money to didn't receive the money due to some failure. Now imagine your money never got refunded. Then where did it go? Ha, I'm sure you have probably encountered this issue before. This is where the concept of ACID comes in.

A- Atomicity

A database should have the ability to consider the entire transaction as failed if even just a part of it fails. This property prevents data loss or corruption. We don't want you contacting customer support that the app stole your money, do we? 😄

C - Consistency

Let's say you were pouring water from a bottle into a bowl. As you pour the water into the bowl, the water in the bottle should be reduced right? Imagine the water in the bottle was increasing instead or was not reducing at all. Hahaha. You'd probably attribute it to dark magic.  Something like this puts the entire pouring process in an erratic state.  

Applying this analogy to a database, imagine deleting a product in an e-commerce system and having a scenario where all the purchase records for that product are still in the database. You just left your database in a terribly inconsistent and broken state. This is why it is important for a database to enforce referential integrity checks.  Consistency my friend, consistency.

I - Isolation

I love this one. Let's say two people were ordering the same item from an online store. The quantity remaining was three. The first person ordered three. Simultaneously, another person ordered the same 3. What happens in this scenario?  How do we ensure that the concurrent transactions do not interfere with one another? How does the database treat this scenario?  As an engineer, you need to be aware of these edge cases. A database needs to have mechanisms for handling isolation properly. To keep this article short, I won't go too deep into this. Maybe in another article, but you get the idea.

D - Durability

Let's use the money transfer example. Let's just say that this time around, the bank's servers lost power in the middle of the transaction right after your balance was deducted. What happens to the transaction?

A durable database ensures that changes made to the data after successful transactions will be saved in the event of system failure.

ACID-compliant databases ensure the highest level of data reliability and integrity. We don't want an instance where your data gets corrupted due to partially completed transactions or external circumstances. That could cause millions to be lost, angry customers, or loss of precious business data.

So the next time you start designing the database for your shiny new app, make sure to give all these a thought. Thankfully, most of the modern database systems take care of these at the core level, but then, you need to be aware of these at a deep enough level to fix issues that may possibly arise.

Hope you enjoyed this article!