Backend Architecture
Pooling: multiple-choice review
Six questions that cut across the whole unit. Each mirrors a decision you make in a real pooling incident — not a definition to recite, but a tradeoff to weigh when the pool is empty, leaking, or fanning into one shared database.
Confirm you can connect pool sizing, acquisition timeouts, connection lifecycle, leaks, and distributed fan-in — the synthesis the individual lessons built toward.
A team makes the database the bottleneck, so they raise the pool from 20 to 100 on an 8-core Postgres box expecting roughly 5x throughput. Throughput drops and latency climbs. Why?
A downstream query that normally takes 5 ms slows to 500 ms; within seconds the whole web tier stops accepting requests even though the database is still up. What is the mechanism, and the first config fix?
After an overnight lull the first morning requests fail with 'connection reset by peer'; nothing deployed and the database is healthy. What happened, and which control is the root-cause defence?
A service times out acquiring connections after running for hours; a restart fixes it for a few hours, then it recurs, all while traffic is normal. Why is enlarging the pool the wrong fix?
A handler checks out a pooled connection, then awaits a slow external HTTP call before running its query. Nothing leaks — try/finally always releases. Why does this still exhaust the pool under load?
A service healthy at one instance (pool 20) starts throwing 'FATAL: sorry, too many clients already' after autoscaling to 50 instances. No pool leaks. What is the fix, and its main correctness cost?
Across the unit the through-line is one chain: a pool amortises connection setup and bounds concurrency, so its size is small and derived from cores (not a big guess); when it empties, the acquisition timeout decides whether you fail fast or starve the web tier; the connections it holds go stale and must be rotated by maxLifetime and validated on borrow; the most common outage is a leak (or hoarding across an await), which a bigger pool only delays and hides; and at scale many pools fan into one max_connections, forcing a transaction-pooling multiplexer that trades away session state. Every answer resolves back to the same discipline — bound the resource deliberately (size, wait, age, return, fan-in) rather than letting an external system bound it for you at the worst moment.