Databases
Connection Pooling
Reusing a small set of open database connections across many requests, instead of opening a new one each time, to avoid exhausting the database.
Every database connection costs memory and setup time, and databases like PostgreSQL cap how many they'll accept. Under load, an app that opens a fresh connection per request quickly exhausts that limit and starts erroring. A connection pool keeps a modest set of connections open and hands them out to requests as needed, then reclaims them, so hundreds of requests share a handful of connections.
This becomes urgent in two situations: serverless and heavily concurrent apps. A serverless function can spin up hundreds of instances at once, each wanting a connection, which overwhelms the database instantly. Poolers like PgBouncer sit in front and multiplex, and managed Postgres services increasingly bundle pooling for exactly this reason.
If your database throws "too many connections" under traffic while CPU looks fine, pooling is almost always the fix. It's cheap insurance that most people only discover the first time a launch takes their database down.