Build fluency in the vocabulary of reusing database connections instead of opening a new one per query.
0 / 5 completed
1 / 5
At standup, a dev mentions maintaining a reusable set of already-established database connections that the application borrows from and returns, instead of opening a brand-new connection for every single query. What is this technique called?
Connection pooling maintains a reusable set of already-established database connections that the application borrows from a shared pool and returns after use, instead of opening a brand-new connection for every single query. Opening a new connection each time is relatively expensive, since establishing a database connection involves real network and authentication overhead. Reusing a pooled connection avoids paying that setup cost repeatedly, significantly improving throughput for a high-query-volume application.
2 / 5
During a design review, the team wants the pool to enforce a maximum number of simultaneously open connections, so the application doesn't overwhelm the database with far more connections than it can handle. Which capability supports this?
A configured maximum pool size limit caps the number of simultaneously open connections, preventing the application from overwhelming the database with far more connections than its own configured connection limit or available resources can actually handle. Allowing an unlimited number of simultaneous connections risks exhausting the database server's resources or hitting its own hard connection limit, causing new connection attempts to fail entirely. This cap is a critical safeguard, tuned to match the actual capacity of the specific database being connected to.
3 / 5
In a code review, a dev notices the pool is configured to validate that a borrowed connection is still alive before handing it to the application, discarding and replacing a connection that's gone stale. What does this represent?
Connection health validation before reuse checks that a borrowed connection is still alive, discarding and replacing one that's gone stale, such as after a network blip silently closed it, rather than handing a dead connection to the application and letting the next query fail unexpectedly. Skipping this validation risks the application encountering a confusing, hard-to-diagnose failure on a connection that looked available but was actually broken. This validation step keeps the pool's connections genuinely usable rather than just nominally present.
4 / 5
An incident report shows the connection pool's maximum size was set far below the application's actual peak concurrent query load, causing requests to queue and time out waiting for an available connection during traffic spikes. What practice would prevent this?
Sizing the connection pool based on the application's actual measured peak concurrent query load ensures enough connections are available during a real traffic spike, rather than forcing requests to queue and potentially time out waiting for one to free up. Setting the pool size arbitrarily without reference to real load risks exactly this kind of bottleneck under peak conditions. This load-informed sizing, balanced against the database's own connection capacity, is a key tuning step for a connection pool serving a production workload.
5 / 5
During a PR review, a teammate asks why the team uses a connection pool instead of simply opening a new database connection for each incoming request. What is the reasoning?
Opening a brand-new connection for every single request incurs real, repeated overhead from the network handshake and authentication involved in establishing that connection. Reusing an already-established connection from a pool avoids paying that cost again for each request, significantly improving throughput for a high-query-volume application. The tradeoff is the added configuration complexity of correctly sizing the pool and handling a stale or broken pooled connection.