Connection Pooling
Practice this topic in a realistic system design interview
In this chapter, we'll break down connection pooling, why creating connections is expensive, and how pools help applications communicate with databases and other services more efficiently.
Let's start with a simple example. Suppose an application needs to query a database. Before it can send the query, it first needs to establish a connection.
Depending on the system, that may involve:
- Opening a TCP connection.
- Performing a TLS handshake.
- Authenticating with the database.
- Allocating resources on both the application and database side.
Only after that setup is complete can the application execute the query.
Now imagine doing all of this for every request. A user sends an API request. The application creates a database connection, runs one query, and closes the connection. Then the next request creates another connection from scratch.
This works, but it is inefficient. The setup cost may be significant compared with the actual query. For a small query, opening the connection can take longer than running the query itself.
Connection pooling solves this by reusing existing connections instead of creating a new one every time.
1. What Is a Connection Pool?
A connection pool is a managed collection of reusable connections.
When a request needs database access, it borrows a connection from the pool. It uses that connection. Then, instead of closing it completely, it returns the connection to the pool. The next request can reuse the same connection.
This avoids repeating expensive connection setup for every operation.
Inside, a pool usually keeps track of a few things:
| Component | Purpose |
|---|---|
| Idle connections | Open connections ready to be borrowed |
| Active connections | Connections currently checked out by requests |
| Wait queue | Requests waiting for a connection |
| Reaper / housekeeper | Closes stale, expired, or unhealthy connections |
| Metrics | Tracks usage, wait time, timeouts, and errors |
When a request borrows a connection, the pool marks it as active. When the request returns it, the connection goes back to the idle list.
In most libraries, calling close() on a pooled connection does not close the real network connection to the database. It just returns the connection to the pool so another request can use it.