Clear your ACID concepts with me —Atomicity

When we work with databases, there can be multiple events that can go wrong. A few of them are:

1. Several clients can update the same data, leading to overwriting each other’ changes
2. Several client can read partially updated data that doesn’t make sense
3. The database can go down and lead to partial updates of write.
4. The application may crash and lead to partial updates of write.
5. Network issues can cut off both databases and applications and lead to partial write updates.

Photo by Rodion Kutsaiev on Unsplash

Databases have to deal with all these faults and avoid catastrophic failures. The safety guarantees provided by the transactions are defined by ACID which stands for

A: Atomicity

C: Consistency

I: Isolation

D: Durability

Let’s start

Atomicity

I would like to talk about atomicity with an example. Consider there is a database that has two tables one menu and another item. The restaurant wants to update its menu, and for that, it hits the menu update API, to update both menu and its item.

While updating the DB, the menu table gets updated but when it tries to update the item table, network failure occurs, and the transaction aborts.

Now we have partial updates on our DB. The menu table is updated, but the item table isn’t.

What we should do now?

One solution is: Restaurants can retry the API call. But that could risk making the same changes twice, leading to duplicates (menu data) or incorrect data.

Now what?

Here comes the atomicity,

If the writes are grouped together into an atomic transaction, and the transaction cannot be completed (committed) due to a fault, then the transaction is aborted and the database must discard or undo any writes it has made so far in that transaction.

So with atomicity, our menu table change will also be discarded and the restaurant or service can retry the API call and update the menus data.

This is ACID atomicity for us.

Isolation

Isolation means that concurrently executing transactions are isolated from each other.
The database ensures that when the transactions have been committed, the result is the same as if they had run serially (one after another), even though in reality they may have run concurrently.

For more understanding of Isolation refer to:

https://fintechcoddler.blogspot.com/2023/03/clear-your-acid-concepts-with-me.html

Durability

Durability in the database promises that once a transaction has been successfully committed, the data won’t be lost even if the database crashes or any other scenario happens.

For more understanding of durability refer to:

https://fintechcoddler.blogspot.com/2023/03/clear-your-acid-concepts-with-me_18.html

Soon, I will be sharing the C of ACID soon.

Copyright © 2023 fintechcoddler.blogspot.com