A bank transfer transaction successfully debits $500 from Account A, but the database crashes before it can credit Account B. After the database restarts and recovers, what does atomicity guarantee?
AThe credit to Account B is completed during recovery, since the debit already occurred
BThe debit to Account A is rolled back, leaving both accounts in their pre-transaction state
CThe transaction is re-executed from the beginning automatically
DThe database flags Account A as overdrawn and waits for a human administrator to resolve it
Atomicity means all-or-nothing: if a transaction cannot complete fully, all of its partial changes are undone. The write-ahead log records the intended changes before they happen; on crash recovery, the database identifies uncommitted transactions and rolls them back. The debit to Account A is reversed, restoring both accounts to their pre-transaction state. This prevents a state where $500 simply vanishes from the system. The log — not a retry — is the mechanism.
Question 2 Multiple Choice
Two concurrent transactions both read an account balance of $1,000 and each independently decide to withdraw $800, which would leave $200. Without isolation controls, what anomaly could occur, and which ACID property prevents it?
ABoth withdrawals succeed, leaving the balance at −$600; prevented by Consistency
BBoth withdrawals succeed, leaving the balance at −$600; prevented by Isolation
COne withdrawal is lost entirely; prevented by Atomicity
DThe account is locked until both transactions complete; prevented by Durability
This is the classic lost-update / write-write conflict anomaly. Without isolation, both transactions read $1,000, both decide to proceed, and both commit a balance of $200 (1000 − 800) — or in a worse variant, one overwrite is lost entirely. Isolation prevents concurrent transactions from seeing or interfering with each other's intermediate states. At the SERIALIZABLE level, one transaction would see the other's committed debit and either fail the constraint check or be blocked. Atomicity ensures each transaction is all-or-nothing but does not protect against concurrent interference.
Question 3 True / False
A database system can be fully ACID compliant and still produce incorrect data if the application code contains logic errors.
TTrue
FFalse
Answer: True
ACID guarantees correct execution of what you ask the database to do — atomicity, consistency relative to schema constraints, isolation from other transactions, durability of commits. It cannot protect against application logic that is itself wrong. If code incorrectly calculates the transfer amount, or updates the wrong account ID, ACID will faithfully and durably commit the incorrect result. Consistency in ACID refers to schema invariants (foreign keys, CHECK constraints), not the semantic correctness of application logic.
Question 4 True / False
'Consistency' in the ACID acronym means the same thing as 'consistency' in the CAP theorem — both ensure that most nodes in a distributed system see the same data at the same time.
TTrue
FFalse
Answer: False
These are completely different concepts that share only a name. ACID consistency means a transaction must preserve all application-defined invariants declared in the schema (constraints, foreign keys, triggers) — it is about transitioning the database between valid states. CAP consistency (linearizability) means all distributed replicas appear as a single up-to-date copy — every read sees the most recent write. Confusing these is a common and consequential error when reasoning about distributed database tradeoffs.
Question 5 Short Answer
Why do some distributed databases deliberately relax ACID guarantees, and which property is most commonly relaxed first?
Think about your answer, then reveal below.
Model answer: Enforcing full ACID requires coordination mechanisms — write-ahead logging, locking protocols, two-phase commit across nodes — that add significant latency and reduce throughput, especially in distributed systems where network communication is slow and unreliable. Isolation is most commonly relaxed first: SQL defines four isolation levels (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) of increasing strictness. Most production databases default to READ COMMITTED or REPEATABLE READ rather than full SERIALIZABLE isolation, accepting specific anomalies (dirty reads, non-repeatable reads, phantoms) in exchange for higher concurrency. Durability is rarely relaxed in traditional RDBMS; some NoSQL systems relax it too by using in-memory storage or eventual persistence.
The CAP theorem formalizes a version of this tradeoff: in the presence of network partitions, a distributed system must choose between consistency and availability. Systems like Cassandra and DynamoDB prioritize availability over strong consistency, implementing 'eventual consistency' instead. This is a practical engineering tradeoff, not a flaw — choosing the right consistency model requires understanding the workload's tolerance for stale reads and conflicting writes.