A service works fine at 10 instances. At 60 instances during a peak, the database starts refusing connections. Explain the arithmetic.

What the interviewer is testing

Whether you reason about aggregate limits across a scaling fleet, which is where per-instance configuration fails.

The arithmetic

Each instance holds a pool — say 20 connections. At 10 instances that is 200, comfortably within a database limit of 500. At 60 instances it is 1,200, well past it.

The configuration was correct at the tested scale and wrong at the peak scale. This is a very common production surprise, because it appears for the first time when autoscaling reaches a level that never occurred in testing.

The fixes

Size pools from the constraint backwards. Take the database's connection limit, reserve headroom for administrative connections, migrations and other consumers, and divide by the maximum instance count — not the typical one.

At 60 instances and a 500 limit with 100 reserved, that is under 7 connections per instance, which is usually adequate and often better than 20.

Introduce a connection proxy. A pooler multiplexes many application connections onto few database connections, decoupling application scaling from database connection limits entirely. This is the standard solution for high-instance-count deployments and is frequently the only way the arithmetic works.

Cap the fleet size in the autoscaling configuration to a number the database can support, so scaling fails safely rather than taking the database down.

The insight that usually improves latency too

Large pools are counterproductive. A database serves queries with finite CPU and disk parallelism; beyond that, additional concurrent connections reduce throughput through context switching and lock contention. Pools are commonly several times larger than optimal, so shrinking them improves performance as well as fixing exhaustion.

What a strong answer adds

The pool wait timeout. Without one, a brief database slowdown causes requests to queue indefinitely on connection acquisition and the service hangs rather than shedding load. It is the setting most often left at infinite, and it converts a slowdown into an outage.

Common weak answers

Raising the database connection limit, which degrades database performance. Capping instances without addressing the pool size.