ACID Transactions

ACID defines atomicity, consistency, isolation, and durability guarantees for database transactions. Together, these properties help a database execute related changes reliably even when errors, concurrent operations, or system failures occur.

A transaction groups one or more database operations into a logical unit of work. Atomicity means the unit is all-or-nothing: if part of the transaction fails, its changes are rolled back rather than leaving only a partial result.

Consistency means a committed transaction preserves the database's defined rules, such as constraints, relationships, and valid data types. The database moves from one valid state to another; the application and database schema together determine many of the rules being enforced.

Isolation controls how concurrent transactions interact. Depending on the database and isolation level, one transaction may be prevented from seeing another transaction's intermediate changes, reducing anomalies such as dirty reads or lost updates.

Durability means that after a transaction is successfully committed, its changes are intended to survive subsequent failures. Databases commonly use mechanisms such as transaction logs and persistent storage to provide this guarantee.

Key points

• Atomicity: a transaction commits as a unit or is rolled back.
• Consistency: committed changes obey the database's integrity rules.
• Isolation: concurrent transactions are controlled to limit interference and anomalies.
• Durability: committed changes survive appropriate system or database failures.
• ACID properties describe transaction guarantees; the exact behavior depends on the database and isolation configuration.

Interview questions

What does ACID stand for?

ACID stands for Atomicity, Consistency, Isolation, and Durability. Atomicity makes a transaction all-or-nothing. Consistency means committed transactions preserve the database's integrity rules. Isolation controls concurrent transaction interactions, and durability makes committed changes persist after normal failures.

What happens if one operation in a transaction fails?

If the transaction is designed to be atomic and the failure causes the transaction to abort, its changes are rolled back. This prevents earlier successful operations in the same transaction from remaining as a partial business operation. The application should handle the error and decide whether to retry or report the failure.

What is isolation, and why does it matter?

Isolation determines what concurrent transactions can observe and how their operations interact. Without appropriate isolation, concurrent requests can produce anomalies such as dirty reads, non-repeatable reads, or lost updates. Databases offer isolation levels that trade stronger guarantees against concurrency and performance costs.

How would you implement an atomic money transfer in a Python backend?

I would put the debit and credit in the same database transaction. The debit should be protected by an appropriate constraint or conditional update so an invalid balance cannot be committed. If either operation fails, the transaction should roll back; only after both succeed should the application commit. I would also consider concurrency behavior and the database's locking or isolation semantics.

Does ACID guarantee that a database can never lose data?

No. Durability is a guarantee about committed transactions under the failure assumptions supported by the database and its storage system. Hardware loss, configuration errors, corrupted backups, or failures outside those assumptions can still cause data loss. Durable systems therefore also need appropriate replication, backups, recovery procedures, and operational controls.