Hard Runtime Diagnostics interview problem
Lock ordering deadlock in transfer path
Written and reviewed by Sahil Srivastav
This problem is available as the same repository challenge in Python, Java, Node.js, and C++. Open the full problem and choose a language
What this interview round tests
A ledger runs correctly for months under mostly sequential traffic, then stops during end-of-day netting when the same account pairs transfer in opposite directions at once. It does not crash or recover without restart.
This is a hard production-debugging exercise because both locks are genuinely required, so the repair must remove circular ordering without weakening transfer atomicity or invalid-transfer checks. It tests whether you can move from operational evidence to a narrow invariant, then make a repair that survives concurrency, retries, failures, or workload growth instead of merely passing one happy-path example.
The scenario
A transfer must hold both participating accounts so observers never see a half-applied debit and credit. Concurrent transfers are valid and account balances must remain conserved.
Each call acquires its source lock before its destination lock. Two reversed transfers can therefore each hold one account while waiting for the other, forming a circular wait.
What you’ll practice
- Reconstructing a wait-for cycle from thread dumps
- Defining one deterministic global lock order
- Preserving atomic debit and credit updates
- Handling same-account and invalid transfers safely
- Stress-testing reversed operations repeatedly
How to approach it
Label the resources held and requested by each blocked worker, then draw the cycle. Parameter role is not a stable ordering because source and destination reverse between calls.
Choose an order derived from immutable account identity and acquire both locks consistently. Confirm liveness under repeated opposite transfers and verify the total balance remains unchanged.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
Try it in a real repository
LeetCode teaches algorithms. Gronex teaches backend coding rounds with real repositories, failing tests, service logic, and production-style constraints. Read the diagnostic brief on this page, then open the challenge workspace when you are ready to investigate the repository.
FAQ
What should I inspect first in Lock ordering deadlock in transfer path?
Begin with the deadlock cycle in the thread dump, account lock identities, opposite-direction workload, and conservation of all account balances. The supplied evidence narrows the failure mode before you touch the implementation, which is the same evidence-first habit expected during a production incident or senior backend interview.
What makes this a hard runtime diagnostics problem?
It is hard because both locks are genuinely required, so the repair must remove circular ordering without weakening transfer atomicity or invalid-transfer checks. The test suite checks the underlying invariant and adverse execution paths, so a local patch or a larger resource limit will not satisfy the challenge.
Which languages can I use for this repository challenge?
The same scenario is implemented in Python, Java, Node.js, and C++. Each language directory includes its own source, evidence or database setup, tests, and verify.sh entry point while preserving the same production invariant.