You add separate connection pools per downstream dependency for isolation. Shortly afterwards the database starts refusing connections. What happened?

What the interviewer is testing

Whether you reason about aggregate resource limits rather than per-component configuration.

What happened

The pools were sized individually and not in total. Ten pools of 50 connections is 500 per instance. Across 20 instances that is 10,000 connections against a database that accepts perhaps 500.

The bulkheading is correct in principle — it prevents one slow dependency from exhausting a shared pool — and the aggregate exceeded a limit one layer down. You have moved the exhaustion rather than removed it.

The fix

Size pools from the constraint backwards. Start with the database's connection limit, subtract headroom for administrative connections and other consumers, divide by the number of application instances at maximum scale, and allocate that budget across the pools by measured demand.

Note the "at maximum scale" — a configuration that works at 20 instances fails when autoscaling reaches 60, and that is a common way this appears in production for the first time during a traffic peak.

Introduce a connection proxy if the arithmetic does not work. A pooler multiplexes many application connections onto few database connections, which is the standard solution for high-instance-count deployments and is frequently the only way to make the numbers fit.

The sizing insight that usually reduces the total

Connection pools are commonly far larger than they should be. A database serves queries with finite CPU and disk parallelism; beyond that, additional concurrent connections reduce throughput through context switching and lock contention. A pool in the region of two to four times the database's core count, per instance, is a starting point — usually much smaller than defaults.

So the fix is often to shrink pools rather than to increase the database limit, which improves latency as well.

What a strong answer adds

Pool wait timeouts. A pool with no timeout on connection acquisition turns a brief database slowdown into an indefinitely hung service, and it is the setting most commonly left at infinite. The pool should fail fast and shed load rather than queue without bound.

Common weak answers

Raising the database connection limit, which degrades database performance. Reverting the bulkheads.