Hard Database Engineering interview problem
Inventory Overselling Under Concurrency
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 warehouse reservation API is correct when requests arrive one at a time, yet sells more units than exist during a burst. Client retries can also create a second reservation for the same logical request.
This is a hard production-debugging exercise because both stock conservation and retry deduplication must hold in the same transaction across several competing sessions. 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
Each request checks available stock, creates a reservation, and reduces inventory. The database must preserve non-negative stock and make a caller-provided idempotency key identify one durable outcome under arbitrary concurrency.
The starter separates the read, decision, and write in a way that permits lost updates. Idempotency is treated as an application pre-check rather than a database-enforced invariant, leaving a race between duplicate requests.
What you’ll practice
- Reproducing a lost-update race with concurrent transactions
- Choosing atomic conditional updates or row locking deliberately
- Enforcing idempotency with a database uniqueness constraint
- Returning one stable result for duplicate requests
- Checking inventory conservation after successful and rejected reservations
How to approach it
Write down the invariant before choosing a lock: total successful reserved quantity cannot exceed the initial stock, and one idempotency key cannot represent two reservations. Then inspect where the current transaction permits either statement to become false.
Exercise the same request in parallel, not only sequentially. The useful fix places the decision next to the protected database state and lets a uniqueness constraint arbitrate duplicate retries.
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 Inventory Overselling Under Concurrency?
Begin with concurrent reservation results, stock invariants, transaction boundaries, lock behaviour, and uniqueness constraints for retry keys. 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 both stock conservation and retry deduplication must hold in the same transaction across several competing sessions. 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.