Exercise 3: Connection Budgeting — Possible Solution
======================================================

Current setup:
  4 API copies x 10 connections = 40, against a limit of 50.

That's safe, but tighter than it looks. The database needs a few
connections for itself and for administrators (PostgreSQL reserves
some for superusers by default), so realistically about 45 are usable.

After the changes:
  5 API copies x 10    = 50
  migration job        = up to 10 (a new PrismaClient, default pool)
  admin script         = up to 10
  Total                = 70  -> over the limit

When the limit is reached, new connection attempts fail, so requests
start erroring during deployments (exactly when the migration job
runs).

A safer budget (about 45 usable):
  5 API copies x 7     = 35
  migration job        =  2
  admin script         =  2
  spare for scaling    =  6

Configuration:

// lib/prisma.ts (API)
const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
  max: Number(process.env.DB_POOL_MAX ?? 7),
  connectionTimeoutMillis: 5_000,     // fail fast instead of waiting forever
  idleTimeoutMillis: 300_000,
});

// scripts use the same file with DB_POOL_MAX=2 set in their environment

If you need more API copies than the database can serve, the real fix
is an external pooler such as PgBouncer (or a managed equivalent) in
front of the database, rather than ever-larger pool settings.

WHY THIS WORKS AS AN ANSWER
------------------------------
Pool size is per client, so the true total is the pool size multiplied
by every process that creates a client, including one-off jobs that
are easy to forget. The answer adds them all up, leaves headroom, makes
the pool size configurable per process, and sets a connection timeout
so an exhausted pool produces a clear error instead of a hung request
(pg waits forever by default).