Checkout is failing because Postgres has hit its 200-connection limit. The on-call engineer wants to raise the limit. Talk me through the right response.

1. Reject the reflex and explain why: each Postgres connection is a separate OS process with its own memory, so raising the ceiling trades a connection error for memory exhaustion and a slower, unstable database. 2. Investigate before acting — inspect pg_stat_activity to see what the connections are actually doing. 3. Identify the usual finding: connections are idle in transaction, not busy — held open while a slow downstream call (a payment provider) completes inside the transaction. 4. Fix the immediate incident: terminate the idle-in-transaction sessions to restore capacity. 5. Fix the code pattern: never hold a database transaction open across a network call to a third party — commit first, then call out, and reconcile asynchronously. 6. Introduce a connection pooler (PgBouncer in transaction mode) so hundreds of application connections multiplex onto a small number of server connections. 7. Bound the application-side pools too, since every replica multiplies its pool size by the replica count. 8. Add the guardrails that make it self-limiting: idle_in_transaction_session_timeout, statement_timeout, and per-role connection limits. 9. Monitor connection utilisation and idle-in-transaction counts as leading indicators, so the next occurrence is an alert rather than an outage.