Hard Database Engineering interview problem
Payment Ledger Consistency
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 payment service records refunds through several independent writes. A timeout or retry can leave the double-entry ledger unbalanced, apply the same refund twice, or move the cached balance away from its journal.
This is a hard production-debugging exercise because financial correctness is a multi-row invariant that must survive exceptions and duplicate concurrent delivery, not merely produce the right happy-path response. 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
Refund processing creates compensating ledger entries and updates the associated balance. Every durable outcome must be atomic, balanced, and uniquely tied to the external refund reference.
The starter commits related mutations separately and relies on an application check for duplicate refunds. Mid-path failure exposes partial state, while concurrent retries can both pass the check and post another refund.
What you’ll practice
- Expressing double-entry balance as a database invariant
- Grouping ledger and balance mutations in one transaction
- Using uniqueness to arbitrate duplicate refund references
- Rolling back cleanly at injected failure points
- Reconciling derived balances against immutable ledger entries
How to approach it
List every row that represents one refund and decide whether any proper database state may contain only a subset. Use failure injection after each write to expose accidental transaction boundaries.
Drive two transactions with the same external reference and let the database decide which one owns it. The losing request should resolve to the existing outcome without adding another debit, credit, or balance adjustment.
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 Payment Ledger Consistency?
Begin with ledger debit and credit totals, refund uniqueness, account balances, injected failure points, and transaction commit state. 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 database engineering problem?
It is hard because financial correctness is a multi-row invariant that must survive exceptions and duplicate concurrent delivery, not merely produce the right happy-path response. 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.