Summary
Connection pooling reuses expensive connections, such as database or HTTP connections, instead of opening a new one per request.
Interview Points
- Creating connections has handshake, authentication, and resource costs.
- Pools reduce latency and protect downstream systems.
- Pool size must match service concurrency and database limits.
- Too many connections can overload the database.
- Monitor wait time, active connections, idle connections, and timeouts.
2-3 Minute Interview Script
“Connection pooling keeps a reusable set of connections to a dependency, most commonly a database. Opening a new connection for every request is expensive because of handshakes, authentication, and resource allocation.
A pool improves latency and throughput, but it also acts as a control point. If every app instance opens too many database connections, the database can collapse under connection overhead.
The important design detail is sizing. Pool size should account for instance count, concurrency, database limits, and query duration. I would monitor pool wait time, active connections, idle connections, and timeout rates.
Interview line: pooling improves reuse, but pool limits are also part of backpressure.”
Follow-Ups
- What happens when the pool is exhausted?
- Why can large pools hurt databases?