Hard Runtime Diagnostics interview problem
Unbounded Cache Heap Exhaustion
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 freight pricing service returns correct quotes but grows until restart while reporting almost no cache hits. Heap evidence points to request and metadata objects retained behind a cache that was intended to hold only 128 reusable entries.
This is a hard production-debugging exercise because the component is named and configured as a bounded cache, but key semantics and ownership make its real cardinality track requests rather than reusable pricing decisions. 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
Pricing depends on a small set of lane, service, and weight attributes that repeat heavily. A bounded quote cache should retain normalized pricing keys and evict older entries while unrelated request metadata dies after each call.
The starter builds keys from overly specific request identity and fails to enforce effective capacity. Logically equivalent quotes miss the cache, while every unique request leaves another retained object graph.
What you’ll practice
- Reading cache-owned retainer paths in a heap capture
- Designing keys from the true pricing inputs
- Enforcing deterministic bounded eviction
- Separating metrics buffers from the leaking owner
- Checking hit rate and retention at doubled workload size
How to approach it
Follow one retained request to the owning cache entry, then compare key fields with the inputs the pricing engine actually uses. Estimate cardinality from production traffic rather than trusting the configured capacity.
Normalize the key and enforce the bound without changing quote output. Verify hot-lane reuse, eviction behaviour, and a retained set that stays flat when request count doubles.
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 Unbounded Cache Heap Exhaustion?
Begin with live-object census, allocation hot spots, a retained request referrer chain, cache hit rate, configured capacity, and doubled-workload retention. 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 the component is named and configured as a bounded cache, but key semantics and ownership make its real cardinality track requests rather than reusable pricing decisions. 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.