Loading...
Loading...
Browse 10 real-world technical and behavioral interview questions about Transactions. Review scenarios, edge cases, and architectural best practices.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.