# Connection pooling > Connection pooling reuses a bounded set of open connections instead of creating a new connection for every database operation. In system design, it reduces connection setup overhead and limits concurrent database work, but only if you budget connections across all application instances and bound the wait for a free connection. Source: https://sysround.com/concepts/connection-pooling Updated: 2026-11-05 ## How connection pooling works Opening a database connection can require a network handshake, TLS negotiation, authentication, and database-side session resources. A pool keeps connections available for reuse, opening them lazily or maintaining a configured minimum. A request borrows a connection, runs its queries or transaction, and returns it in a cleanup block even if the operation fails. For example, 200 concurrent HTTP requests might share 20 database connections because many requests are not accessing the database at the same moment. When all connections are busy, new borrowers wait in a bounded queue or fail when an acquisition deadline expires. Pool acquisition timeouts, query timeouts, and transaction timeouts control different waits; configure them within the overall request deadline rather than treating one timeout as protection for everything. Pool limits usually apply per process, not per service. If 30 processes each allow 20 connections to the same database, they can open 600 connections; background workers, other services, and overlapping deployments add to that total. An application-side pool reuses connections within one process. A database proxy can also share backend connections across many clients; transaction pooling assigns a backend for a transaction, which reduces idle backend usage but can restrict session-dependent features. Neither approach increases the database's underlying query capacity. ## Worked example: Budgeting checkout connections during a traffic surge Suppose a checkout database has a configured limit of 500 connections. Reserve 100 for other services, maintenance, and recovery, leaving a ceiling of 400 for checkout. With 20 application processes and a maximum pool size of 15 each, checkout can open 300 connections. At 4,000 database transactions per second and an average connection hold time of 20 milliseconds, average busy concurrency is about 80; this is a starting estimate, not proof of peak capacity. Scaling to 30 processes raises the connection ceiling to 450, exceeding the budget. Cap scaling, lower per-process limits, or use shared backend pooling. Validate database throughput under load, bound acquisition waits, and keep payment-provider calls outside database transactions. ## Trade-offs - **Less setup overhead, more persistent resource use.** Reusing connections avoids repeated setup, but even idle connections consume database and application resources. - **Smaller pools protect concurrency but increase waiting.** A pool that is too small can leave useful database capacity idle while requests wait for a connection. - **Larger pools can reduce throughput.** More concurrent queries can increase CPU contention, disk pressure, and lock waits, making each connection stay busy longer. - **Local limits do not enforce a global budget.** Autoscaling and rolling deployments multiply independent pools unless you coordinate limits or introduce a shared pooling layer. - **Shared connections require careful cleanup.** Unfinished transactions or leaked session settings can affect later borrowers unless the application or pool reliably resets them. - **Proxy pooling adds operational and compatibility costs.** A proxy adds another component to operate, and transaction pooling requires checking support for session state, temporary tables, and prepared statements. ## When to use it in a system design interview - A request-serving application repeatedly accesses a database, making per-operation connection setup unnecessary overhead. - Flash-sale traffic or scheduled worker bursts could overwhelm the database with concurrent operations. - The application tier scales independently of a database with a finite connection and execution budget. - Many short-lived application instances would otherwise create large numbers of mostly idle database sessions. ## How to bring it up in the interview - Start with a database-wide budget: include every service, worker, application process, and deployment overlap, while reserving connections for operations and recovery. - Estimate average busy connections as database operations per second multiplied by average connection hold time, then validate with load tests and tail latency; the database's maximum connection setting is not a throughput target. - State the exhaustion policy explicitly: bounded waiting, an acquisition timeout within the request deadline, and load shedding rather than an unlimited queue or immediate retry loop. - Keep transactions short and avoid holding a connection during payment calls or other unrelated network waits; interviewers may probe how lock waits or slow queries exhaust the pool. - Explain what you would measure: active and idle connections, acquisition latency, waiter count, timeouts, connection hold time, and database saturation; expect follow-up questions about autoscaling and reconnect storms after failover. ## Common mistakes - Setting the pool size equal to the number of HTTP requests or worker threads without measuring database concurrency needs. - Counting one pool per service while ignoring multiple processes, replicas, background jobs, and rollout overlap. - Responding to pool exhaustion by enlarging the pool before checking slow queries, lock contention, leaked connections, and long transactions. - Holding a database transaction open while waiting for an external payment provider or another service. - Assuming a pool makes failed transactions safe to retry; ambiguous commits still require idempotency or reconciliation. ## Interview questions where it comes up - [Design a ticket booking system like Ticketmaster](https://sysround.com/questions/design-ticketmaster): Flash-sale admission control must bound database connection use so waiting seat transactions do not exhaust checkout capacity. - [Design a flash giveaway: 6 million burgers in an hour](https://sysround.com/questions/design-flash-sale): A surge of claim requests needs bounded database concurrency and acquisition waits alongside atomic inventory updates. - [Design a distributed job scheduler](https://sysround.com/questions/design-job-scheduler): Cron bursts require budgeting database connections across dispatchers and workers so adding execution capacity does not overload durable job-state storage. ## FAQ ### What is a database connection pool? A database connection pool manages reusable connections that application code borrows and returns. It avoids opening a connection for every operation and places a limit on how many connections that pool can use at once. ### How do you choose a database connection pool size? Start with measured database capacity and a connection budget shared across all clients. Estimate busy concurrency from operation rate and connection hold time, then load-test candidate sizes while watching acquisition latency and database saturation. Include maximum replica counts and deployment overlap in the budget. ### What happens when a connection pool is exhausted? New borrowers either wait or fail, depending on the pool's configuration. Bound the wait and reject excess work before requests accumulate without limit. Investigate long-running queries, lock waits, connection leaks, and traffic growth before increasing the pool size. ## Related concepts - [Back-of-the-envelope estimation](https://sysround.com/concepts/back-of-the-envelope-estimation) - [Autoscaling](https://sysround.com/concepts/autoscaling) - [Load shedding](https://sysround.com/concepts/load-shedding) - [Backpressure](https://sysround.com/concepts/backpressure) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.