Atomicity Consistency Isolation Durability (ACID)

ACID refers to a database system’s four transaction properties: atomicity, consistency, isolation and durability.

Transactions: A transaction is a single logical unit of work which accesses and possibly modifies the contents of a database. Transactions access data using read and write operations.

In order to maintain consistency in a database, before and after the transaction, certain properties are followed. These are called ACID properties. It is a sequence of operations that satisfies these properties.

Let's go ACID properties in detail:

Atomicity: Nothing or All

Atomicity is a property that ensures that a database follows the all or nothing rule. In other words, the database considers all transaction operations as one whole unit or atom. There is no midway i.e. transactions do not occur partially.

It involves the following two operations.

Abort: If a transaction aborts, changes made to database are not visible.
Commit: If a transaction commits, changes made are visible.

Thus, when a database processes a transaction, it is either fully completed or not executed at all. If a single portion of the transaction fails, the whole transaction will fail.

For example, user X wants to withdraw $50 from his account and then transfer it to the account of user Y. Each transaction (withdrawing $50 from account X and transferring $50 to account Y) is counted as separate. If the first transaction (withdrawing $50) fails because (say) the server crashes during the transaction, user X cannot transfer the money to user Y.

Consider the following transaction T consisting of T1 and T2: Transfer of 50 from account X to account Y.

Initial Balance: X=100 , Y=200

T1 Transaction:

Read(X)

X= X-50

Write(X)

T2 Transaction:

Read(Y)

Y=Y+50

Write(Y)

If the transaction fails after completion of T1 but before completion of T2.( say, after write(X) but before write(Y)), then amount has been deducted from X but not added to Y. This results in an inconsistent database state. X has left $50 in his account as $50 has been deducted but Y has $200(same as before). Transaction got failed. What if Y doesn't get $50 and X's reaction would be😱

Hence, Atomicity is particularly important to mitigate damage in case of database server crashes. If a non-volatile database crashes in the middle of a transaction, all changes done will be discarded or rolled back to avoid sending partial results to the production database.

Hence we can say Atomicity is required. Transaction (T1+T2) takes place at once.

Consistency:

Consistency is key to maintain data integrity. Consistency is a property ensuring that only valid data following all rules and constraints is written in the database. When a transaction results in invalid data, the database reverts to its previous state, which abides by all customary rules and constraints.

For example, if user X wants to withdraw $1,000 from his account, but only has a balance of $500, consistency will prevent him from withdrawing money and the transaction will be aborted.

Current Balance: $500

Wants to withdraw: $1000

How?😳

"User X hasn't sufficient balance!"

Isolation:

Isolation ensures that multiple transactions can occur concurrently without leading to the inconsistency of database state. It is a property that guarantees the individuality of each transaction, and prevents them from being affected from other transactions.

For example, user X withdraws $100 and user Y withdraws $150 from user Z’s account, which has a balance of $1,000. Since both A and B draw from Z’s account, one of the users is required to wait until the other user transaction is completed, avoiding inconsistent data.

User Z Balance: $1000

User X wants to withdraw: $100

User Y wants to withdraw: $150

One user has to wait till other's transaction is being completed. For e.g. Y has to wait till X's transaction is in progress.

Durability

Durability is a property that enforces completed transactions, guaranteeing that once each one of them has been committed, it will remain in the system even in case of subsequent failures.

If a transaction is successful, all changes generated by it are stored permanently.

Let's say in above example, user Y may withdraw $100 only after user X’s transaction is completed and is updated in the database. If the system fails before X’s transaction is logged in the database, X cannot withdraw any money, and Z’s account returns to its previous consistent state.

So, once the transaction has completed execution, the updates and modifications to the database are stored in and written to disk and they persist even if a system failure occurs.