Lets first understand what ACID is.
ACID is the acronym used to describe the safety guarantees of transactions in a database.
So what exactly is a transaction ?
Transaction is a short sequence of interactions with the database(e.g, find a record and modify it), which represents one meaningful activity in the user's environment. It is a way for application to group several reads and writes together into a logical unit.
e.g. the transfer of money from one account to another. In this case, money should be debited from one account and credited to another, so there are two updates need to be performed so that the data is consistent, both these update operations constitute a transaction.
So why do we need safety guarantees ?
In data systems, many things can go wrong, such as the database software or hardware may fail at any time(including in the middle of operation), application may crash at any time, Interruptions in the network, several clients may write to the database at the same time overwriting each other's changes, client may read data that doesn't make sense because it has only partially been updated(only debit update has happened an not the credit)
If there were no transactions, application had to deal with the above failures. Transactions were created with the purpose to simplify the programming model for application accessing database, so an application using transactions is free to ignore these error scenarios, because the database takes care of them instead. Any database that is an ACID compliant, takes care of the transactions and any failure might occur.
Lets understand what these safety guarantees are:
- Atomicity: Transaction must be of the all-or-nothing type. If a transaction is aborted, the database must discard or undo any changes it has made so far in that transaction
- Consistency: A transaction reaching its normal end, preserves the consistency of the database. In other words, each successful transaction by definition commits only legal results.
- Isolation: Events within a transaction must be hidden from other transactions running concurrently. The techniques that achieve isolation are known as synchronization.
- Durability: Once a transaction completed successfully, any data that has written will be persisted, even if there is a hardware fault or the database crashes.
Coming back to our question, why consistency doesn't belong in ACID, if you see in Atomicity, database has to ensure 'all-or-nothing'. In isolation, its database's responsibility to isolate the transactions from each other, In durability, its database's responsibility to ensure that the data is persisted.
But the idea of consistency depends on the application. meaning it's the application's responsibility to define its transactions correctly so that they preserve consistency. If we take the example of money transfer, if application defines debit update and credit update as separate transactions, then according to atomicity, it is not guaranteed that whenever the debit update occurs, credit update will occur as well, since the atomicity only guarantees 'all-or-nothing' for operations in single transaction. so if database crashes after the debit update has performed by db, and the credit update was not performed, the database will be in an inconsistent state.
So Atomicity, Isolation and durability are properties of the database, where Consistency is the property of an application.
References
i. 'Designing Data-Intensive Applications' by Martin Kleppmann
ii. 'Principles of Transaction-Oriented Database Recovery' by Theo Harder and Andreas Reuter