Hard Database Engineering interview problem
One Tenant's Volume Slows Every Tenant
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 multi-tenant event store behaves well until one customer’s volume grows dramatically. After that, even tiny tenants pay the cost of scanning partitions populated almost entirely by somebody else’s data.
This is a hard production-debugging exercise because logical tenant filtering can still return correct rows while the physical plan silently touches every partition. 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
Events are physically partitioned and every read is scoped to one tenant and a bounded time range. Tenant isolation depends on the query predicate matching the partitioning strategy closely enough for PostgreSQL to prune irrelevant storage.
The current schema and query path do not expose the tenant boundary in a form the planner can prune. One hot tenant expands the work performed for all tenants, violating the operational reason the table was partitioned.
What you’ll practice
- Matching partition keys to real tenant access patterns
- Verifying partition pruning with EXPLAIN
- Designing tenant-aware indexes inside partitions
- Keeping time-range reads bounded for both large and small tenants
- Separating result correctness from workload isolation
How to approach it
Compare plans for a small tenant and the dominant tenant, looking at which partitions are opened rather than only final row counts. Correct SQL that filters late is still an isolation failure.
Make the tenant boundary available as early as possible to the planner. Validate the repair with plan shape and scanned-row budgets so a new large partition cannot regress every other customer.
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 One Tenant's Volume Slows Every Tenant?
Begin with partition definitions, tenant predicates, EXPLAIN plans, rows removed by filters, and query latency for small versus dominant tenants. 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 logical tenant filtering can still return correct rows while the physical plan silently touches every partition. 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.