Connection pooling and its key parameters

WHAT THIS TESTS Whether you understand the real cost of opening database connections and can reason about pool sizing as a bounded shared resource.

A GOOD ANSWER COVERS Establishing a database connection is expensive: a TCP handshake, possibly TLS negotiation, and authentication, plus server-side memory allocation. A connection pool maintains a set of already-open connections and hands them out to application requests, returning them to the pool when done instead of closing them. This eliminates per-query setup latency and caps the total connections hitting the database. Two important parameters are maximum pool size and connection acquisition timeout. Setting max size too high can exhaust the database's own connection limit and waste memory, and counterintuitively can slow throughput because the database thrashes; setting it too low starves concurrent requests, which queue or fail. The acquisition timeout controls how long a request waits for a free connection: too short causes spurious failures during bursts, too long lets requests pile up and masks an undersized pool.

COMMON WRONG ANSWERS Assuming a larger pool is always faster, ignoring that the database has its own hard connection ceiling, or thinking the pool removes all latency rather than amortizing setup cost.

LIKELY FOLLOW-UPS How to size the pool relative to CPU cores and database max_connections; idle and max-lifetime timeouts to recycle stale connections; pool exhaustion symptoms.

ONE CONCRETE EXAMPLE An API set its pool max to 500 per instance across 20 instances, demanding 10000 connections from a database capped at 1000. The database refused connections and stalled. Reducing max size to 20 per instance kept total demand under the limit and throughput actually rose, since the database stopped context-switching across thousands of connections.