Connection pools — when a slow query drains them
A service keeps a pool of open database connections and lends one to each request, because opening one is slow and every connection costs the database. Connections in use ≈ requests a second × hold time, so a slow query drains the pool at unchanged traffic; a bigger pool stops the errors but not the slowness, and every instance's pool adds up at the database.
12 minMediumStation: Connection poolsMembers lesson
Membership isn’t open yet. The free lessons are open — 16 of them.
- Queueing & Little's law
- Connection pools
- Server capacity & scaling up
- Capacity math
What you'll be able to do
- 1Explain why a service reuses a pool of open connections instead of opening one per request, and what each open connection costs the database.
- 2Predict when a pool runs out — connections in use ≈ requests per second × hold time — including when a slower database drains it at unchanged traffic, and what callers see then.
- 3Choose a pool size that covers the peak without swamping the database, with every instance's pool together under the database's connection limit.
Inside the lesson
- steps
- 10
- questions
- 7
- simulations
- 3
You guess first, then run the system and see if you were right.
Step 1 · The setup
At the last stop, Timetable's database had connections to spare. Now its team runs a lean pool of 3 — three connections kept open, each lent to one lookup at a time — sized for rush hour: 400 lookups a second × 5 ms needs about 2. A normal afternoon needs about 1.
The lookups come from two places: riders' apps, about 150 a second, and the screens at stations, about 50. Riders get their answer in about 10 ms.
Now replay Monday's dropped index — the shortcut that takes the database straight to a stop's rows — with the same traffic and the same 20 ms per lookup instead of 5, but with the lean pool of 3.
Steps 2–10 are for members