ACID is an acronym for Atomicity, Consistency, Isolation, and Durability. A transaction is a logical unit of work that reads and updates the contents of a DATABASE in some instances. Transactions employ read and write operations to access data. To maintain database consistency, certain properties are followed before and after a transaction. They are referred to as ACID properties. LET us now take a closer look at each of these characteristics:

• Atomicity: When a transaction is ATOMIC, it means that it either happens all at once or it does not happen at all. There is no intermediate ground, which means that there are no steps to transactions. Each transaction is viewed as a single entity that is either completed or not. It entails the two processes listed below.
  • Abort: Any database updates are lost if a transaction aborts.
  • Commit: When a transaction commits, the changes contained within it become visible. 
    Atomicity is often known as the "all or nothing rule.

Think about the following scenario: T, which is made up of two separate transactions: T1 and T2. A $100 transfer was made from account X to account Y.
The amount deducted from X but not added to Y is deducted if a transaction fails after T1 but before T2 (for example, after write(X) but before write(Y)). As a result, the database is in a state of inconsistency. As a result, to ensure that the database state is legitimate, the transaction must be completed in its entirety.

• Consistency: To ensure that the database is consistent, integrity constraints must be maintained both before and after the transaction. It relates to the accuracy of a database. As seen in the sample above, the total amount before and after the transaction must be maintained.
  The total before T is 500 + 200 = 700.
  The total after T is 400 + 300 = 700.
  As a result, the database is well-organized. There is inconsistency when T1 succeeds but T2 fails. As a result, T isn't finished.
• Isolation: This property ENSURES that several transactions can run concurrently without generating database state inconsistencies. Transactions are carried out in a non-disruptive manner. Changes in one transaction are not visible to other transactions until the change for that transaction is put to memory or committed. This feature ensures that concurrently running transactions provide the same state as if they were run sequentially in some order. To better understand Isolation, consider the following scenario. Let us say X and Y are both 500, and there are two transactions T and T."

Assume T has been operating until Read (Y), after which T" will start. T" reads the correct value of X but the incorrect value of Y as a result of this interleaving, and the sum computed by T" (X+Y = 50, 000+500=50, 500) is inconsistent with the sum at the end of the transaction: T = 50, 000 + 450 = 50, 450 (X+Y = 50, 000 + 450 = 50, 450).
This results in a database inconsistency due to the loss of 50 units. As a result, transactions must be carried out in isolation, and modifications should be seen only after they have been written to the main memory.

• Durability: This property ensures that database updates and modifications are stored and written to disk after the transaction has concluded and that they survive even if the system fails. These modifications are now permanently recorded in nonvolatile memory. As a result, the transaction's effects are never lost.

Each transaction is a series of actions that works as a single unit, provides consistent outcomes, is separated from other processes, and the modifications it makes are durably stored, according to the ACID properties.