Scaling data / Intermediate / 5 min
Connection pooling
Borrow database connections instead of opening one per request. Size the pool, watch the queue, and hit the database limit.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A pool keeps a fixed set of open database connections and lends one to each request, which hands it back when done.
- Why it matters
- New connections are slow and databases accept only a few hundred, so opening one per request wastes time and hits the limit.
- The trade-off
- Too small a pool queues requests; too big a pool across many app servers overloads the database, so size it from load × query time.
- Say it in an interview
- "Pool size ≈ requests per second × query time, plus headroom; with many app servers I put PgBouncer in front of Postgres."
Check yourself
Why reuse database connections instead of opening one per request?
Answer: Opening one costs handshakes and login, and the database allows only a limited number. Each new connection pays TCP, TLS and authentication, and databases cap connections (Postgres often at 100).
80 requests/s, each holding a connection for 50 ms. About how many connections are busy on average?
Answer: 4. Little’s law: busy = arrival rate × time held = 80 × 0.05 = 4.
What happens when every pooled connection is busy?
Answer: New requests wait in a queue and fail after a timeout. The pool caps load on the database; requests queue briefly and time out if the wait is too long.