Backend Architecture
Pooling: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s core mechanisms — why a pool exists, how to size it, what the acquisition timeout defends, why connections go stale, how leaks drain a pool, and why fan-in forces a multiplexer — without looking back at the lessons.
- 01Why is opening a database connection expensive, and what two jobs does a pool do about it?
- 02Why does raising the pool size past a small number reduce throughput, and what is the HikariCP sizing formula?
- 03What happens when a request needs a connection but all are busy, and how should the acquisition timeout be set?
- 04Why can a pooled connection be dead while the pool thinks it is open, and what three controls keep the pool fresh?
- 05What is a connection leak, why is a bigger pool a poor fix, and what is the related hoarding trap?
- 06Why does a horizontally scaled fleet overflow one database, and how does PgBouncer transaction pooling solve it — at what cost?
If you could reconstruct each answer from memory, you hold the unit’s spine: a pool amortises expensive setup and bounds concurrency; its size is small and derived from cores, not guessed large; the acquisition timeout decides fail-fast vs thread starvation; connections go stale behind the pool’s back and must be rotated by maxLifetime (under the DB timeout) and validated on borrow; the most common outage is a leak or a hoard, fixed by guaranteeing the return rather than enlarging the pool; and at scale many pools fan into one max_connections, forcing a transaction-pooling multiplexer that trades session state for the ratio. The connection is a hard, shared, expensive resource — bound it deliberately at every layer.