Connection Pool Sizing
Choosing how many concurrent connections a service holds to a datastore, where both too many and too few cause outages.
The instinct is that a larger pool means more throughput, and beyond a modest point the opposite is true — which makes this one of the most common self-inflicted performance problems.
A database serves queries with finite CPU and disk parallelism. Beyond that, additional concurrent connections do not add throughput; they add context switching, lock contention and memory per connection, so throughput falls and latency rises. The frequently cited guidance of roughly two to four times the core count is a starting point rather than a rule, and it is far smaller than most default configurations.
The failure at the other end is exhaustion: a pool too small for the concurrency, so requests queue waiting for a connection and the service appears slow with the database idle. The distinguishing symptom is high application latency with low database utilisation, and it is often misdiagnosed as a database problem.
The estate-level trap is the one that causes outages: fifty service instances each with a pool of 20 is a thousand connections against a database that accepts 500. Each service is configured reasonably; the aggregate is not. Pool sizes must be reasoned about in total, and a shared connection proxy is the usual answer at that scale.
The related failure that will find any misconfiguration: a pool that does not time out waiting for a connection turns a brief database slowdown into an indefinitely hung service.