Connection pools and the problem they solve

WHAT THIS TESTS Whether you understand that opening a database connection is costly and that reusing connections is essential for a concurrent web application.

WHY IT EXISTS Creating a connection involves a TCP handshake, often TLS negotiation, an authentication round trip, and server-side memory allocation for the session. Doing this on every single request adds meaningful latency and load that scale badly with traffic.

A GOOD ANSWER COVERS A connection pool is a managed cache of open database connections. When a request needs the database, it borrows a ready connection from the pool, uses it, and returns it for the next request rather than closing it. This amortizes the expensive setup across many requests, so individual queries see only the cost of execution, not connection establishment. It also bounds the total number of connections the application opens against the database. In a multi-threaded web application without a pool, every concurrent request opens its own connection, pays full setup latency, and then closes it. Under load this both slows every request and can exhaust the database's maximum connection limit, causing rejected connections and cascading failures.

COMMON WRONG ANSWERS Thinking connecting is trivially cheap, confusing the pool with a query cache, or believing the operating system transparently reuses closed connections.

LIKELY FOLLOW-UPS How pool size is chosen; what connection.close() does with a pool (it returns, not closes); idle timeouts; symptoms of pool exhaustion.

ONE CONCRETE EXAMPLE A web app handling 1000 requests per second without a pool tries to open 1000 connections per second, each costing several milliseconds of handshake, swamping both the app and the database. With a pool of 20 reused connections, those 1000 requests share the warm connections, response times drop sharply, and the database sees a stable, bounded connection count.