Top 12 Transactions Interview Questions
Browse 12 real-world technical and behavioral interview questions about Transactions. Review scenarios, edge cases, and architectural best practices.
Explain ACID using a bank transfer of 100 from one account to another, and tell me what isolation protects you from.
In a transfer, atomicity means the debit and credit commit together or not at all, consistency means declared constraints such as a non-negative balance still hold, isolation stops concurrent transactions seeing or overwriting each other's half-done work, and durability means a confirmed commit survives a crash.
A method with REQUIRES_NEW was meant to save an audit row even when the main transaction fails. When does it work, and when does it deadlock?
REQUIRES_NEW suspends the caller's transaction and commits the audit on a second connection, so the row survives a later rollback if the call goes through the Spring proxy. It hangs when the audit touches rows the suspended transaction has locked, or when every thread holds one pooled connection and waits for another.
Two doctors can go off call only if at least one remains. Both check the rule at the same moment, both see two doctors on call, and both go off call. What isolation problem is this, and what actually fixes it?
This is write skew: two transactions read the same set, each writes a different row, and the pair commits a state neither would have produced alone. No row-level constraint can catch it because the invariant is a property of the set, so the fix is either serializable isolation, a lock on something both transactions must touch, or remodelling the invariant onto a single row.
Two transactions each check a rule, then both commit changes that break it, and neither overwrote the other's row. What happened?
This is write skew. Both transactions read the same snapshot, decide independently, and write disjoint rows, so there is no write-write conflict for the engine to catch. The invariant spanned rows it never saw as related, so either make the conflict physical or use true serialisability.
You are getting a handful of deadlock errors an hour under load. How do you find the cause, and how do you stop them?
A deadlock is a cycle in the wait-for graph, so read the engine's own report to get both statements and the locks each held. Nearly all of them come from two code paths taking the same rows in different orders; impose one order, shorten transactions, and retry, because a deadlock is always safe to retry.
What happens between a user clicking confirm in a wallet and the transaction landing on chain?
A wallet transaction signing flow chooses nonce and fee fields, encodes the transaction, signs the hash locally with the private key and sends only the signed transaction to an RPC node for mempool broadcast. Use this wallets answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects transactions to the point an interviewer is testing.
Walk me through the transaction isolation levels and which anomalies each one permits.
Each level is defined by the anomalies it allows: READ COMMITTED permits non-repeatable reads and phantoms, PostgreSQL's REPEATABLE READ is snapshot isolation so it prevents both yet still permits write skew, and only SERIALIZABLE rules out all four.
A client times out and retries your POST /payments call. How do you make that endpoint idempotent?
Take an idempotency key from the client and store it in a uniquely-constrained row written in the same transaction as the effect, so the dedupe record and the work commit together. Replay the stored response on a repeat, refuse a retry arriving mid-flight, and expire keys past the retry horizon.
A user submits the form twice and you get two identical orders. Why did the check-then-insert not prevent it, and how do you fix it in the database?
Two transactions can each run the SELECT before either commits, so neither sees the other and both inserts succeed. The fix is a serialisation point the database owns - a unique index on a natural or client-supplied key - plus a defined answer for whoever loses the race. It also connects idempotency to the point an interviewer is testing.
A worker picks up the job you queued and cannot find the row it was told about. What went wrong?
The job was enqueued inside an open transaction, so the row was invisible to the worker's connection until commit, and a fast worker won the race. Register the side effect with transaction.on_commit so it fires after the outermost atomic block commits, and never if it rolls back.
What does it mean for a concurrent schedule to be serialisable, and how does two-phase locking guarantee it?
A schedule is serialisable when its effect matches running the same transactions one after another in some order, which is the criterion isolation is defined against. Two-phase locking achieves it by forbidding a transaction from acquiring any lock after releasing one, and the price is deadlock.
The inner service threw, you caught the exception in the caller, and then the commit failed with UnexpectedRollbackException. Why?
The inner method joined the caller's transaction, so its rollback rule marked the one physical transaction rollback-only. Catching the exception hides it from your code but not from the transaction manager, which then refuses to commit. Use REQUIRES_NEW when the inner work must be able to fail alone.