Hard Database Engineering interview problem
Connection Pool Exhausts After Failed Requests
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 small connection pool is sufficient under ordinary traffic, but a short sequence of failed customer lookups drains every available connection. A restart appears to repair the service while PostgreSQL simultaneously reports sessions sitting idle in transaction.
This is a hard production-debugging exercise because the visible timeout happens requests after the original exception, and the resource leak is coupled to database transaction hygiene. 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
The reporting service borrows connections from a shared pool for both successful list queries and lookups that may raise a not-found error. Borrowed sessions must return to the pool promptly and in a state that is safe for the next request.
The happy path returns what it borrows, while an exception bypasses cleanup. Other paths return a connection without closing its transaction, retaining snapshots and locks even though the application believes the connection is available.
What you’ll practice
- Following ownership across connection acquisition and release paths
- Using structured cleanup for both success and exception cases
- Committing or rolling back before a session re-enters the pool
- Interpreting idle-in-transaction sessions in pg_stat_activity
- Preserving report behaviour while repairing lifecycle guarantees
How to approach it
Inventory every point where the report service acquires a connection and draw the corresponding release path. Then force each query and transformation step to fail in turn and ask whether ownership is still discharged.
A pool slot being returned is only half the invariant. Inspect the transaction state at return time and make cleanup explicit so the next borrower never inherits a snapshot, failed transaction, or held lock.
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 Connection Pool Exhausts After Failed Requests?
Begin with pool acquisition counts, exception paths, transaction state, and PostgreSQL pg_stat_activity output for the service sessions. 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 the visible timeout happens requests after the original exception, and the resource leak is coupled to database transaction hygiene. 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.