This question separates engineers who treat the pool as a config knob from engineers who understand it as a concurrency governor. The interviewer wants the pool's mechanics and the failure mode you hit when it saturates.
The mental model: the pool is a semaphore over an expensive resource.
Opening a PostgreSQL connection isn't free: TCP handshake, TLS if enabled, authentication round trip, and a backend process spawned server-side. That's why pools exist. Each pooled connection is a checked-out resource: the app borrows it, runs one transaction, and returns it.
The sizing math matters. A database sustains roughly cores × optimal-concurrency-per-core concurrent queries — CPU-bound work at about 2× cores. If every pooled connection sits in an open transaction waiting on an upstream service, the pool fills with connections doing nothing but waiting. That produces the classic deadlock: a pool of 20, twenty requests each holding a connection while calling an API that queries the same pool — all twenty block, and the API's queries can never acquire a connection. The fix is a separate pool for the outbound call, or explicit acquisition timeouts so the borrower fails fast instead of queueing forever.
What happens at exhaustion depends on the client library. Many drivers block until connectionTimeout expires — requests pile up, threads multiply, and latency goes from single-digit milliseconds to seconds. That's the flat latency cliff you see in the trace. Other drivers throw "pool exhausted" immediately. Blocking is fine if the database is merely slow and the queue will drain; if the saturation is a deadlock, blocking just compounds it, and fail-fast plus a retry with backoff is the safer posture.
Tradeoffs and edge cases: pool size is a latency decision, not a memory decision — too small throttles throughput, too large wastes backend processes, each consuming RAM. Watch for connection leaks (a borrowed connection never returned), idle timeouts racing the server-side kill, and connections held open across an external call, which is how pools die. The strong closing points: monitor checkout time as the canary for saturation, and treat acquisition timeout as a first-class error path, not a log line.