The API CPU is low but booking latency is rising. Why might adding tasks make it worse?

Say it in 30 seconds

Say it like this (20-30 seconds)

Requests can be waiting for database connections or the same event row rather than using CPU. Each MiniTickets API process has a pool of ten connections, so adding tasks raises potential database concurrency and hot-row waiters. I would inspect pool waits, transaction duration and lock contention before scaling. The code bounds connection acquisition and statements, but admission control and shorter transactions are often more useful than sending additional concurrent work into a saturated database.

The deeper answer

The pool reuses connections instead of reconnecting for each query. Its maximum is per process, not per deployment. A deployment with overlapping old and new tasks can therefore have more connections than the steady task count suggests, alongside migrations and operator sessions.

A booking waiting on the event lock already holds a database connection. The outbox relay also holds a transaction while publishing to SNS. Those waits can consume a pool even when Node is doing little CPU work. The current pool uses a two-second connection timeout and a five-second statement timeout, including SQL lock waits; these are not a single end-to-end request deadline.

I would correlate increased latency with active sessions, lock waits, query plans and outbox publishing delays. Reduce unnecessary work, protect admission and keep transactions short before enlarging the pool. A larger database or more connections can help only after identifying the constrained resource; it cannot parallelize conflicting updates to one event row.

Counter-questions

Why not set the pool to the database maximum?

Every API process would compete for that whole budget. Reserve capacity for deployment overlap, migrations, administration and other clients, then size per-process pools from the total connection budget.

Does a statement timeout guarantee a fast request?

No. A request can run several statements, wait for acquisition or perform network work outside SQL. Timeout scopes need an overall latency budget and safe handling of ambiguous responses.

What evidence would justify more API tasks?

CPU or independent request execution may be the bottleneck while database headroom remains. If waits instead centre on one row or saturated Postgres, more tasks can increase queueing and failure rates.

Where in MiniTickets

Read Rds postgres, then inspect the rds-postgres piece →.

apps/api/src/db/client.ts → pool