Capacity has several limits
Taskboard receives a burst of task-list requests. Slow responses could come from JavaScript CPU work, waiting for a database connection, a costly query, or sending too much data. Adding more API instances before identifying the limit can make Postgres busier without helping.
Follow where time goes
Node handles many I/O waits without dedicating one JavaScript thread to each request. That does not make CPU-heavy synchronous code free. A long loop or synchronous computation blocks other callbacks in the same event loop. Node's event-loop guidance.
Postgres access has another limit. A connection pool contains a bounded number of connections. When all are busy, requests wait for one. Holding a transaction open during a provider call wastes that capacity.
4 API replicas × 10 pool connections = 40 possible API connections
Workers and migrations need additional database capacity.
The calculation describes a budget, not a throughput prediction. Query duration, transaction contention, and Postgres resources determine how much useful work those connections perform.
Reduce work before caching
Task-list endpoints need bounded pagination and stable ordering. An index can help Postgres locate tenant tasks without scanning unrelated rows. The query plan reveals whether the database uses that index and how many rows it examines.
A cache adds invalidation and tenant-scope requirements. A key that contains only task-list can serve one company's result to another. A correct key also needs the workspace, authorization scope where relevant, filters, sort order, and page identity. Taskboard does not claim a Redis cache merely because this course explains one.
Backpressure means limiting admitted or concurrent work when capacity is exhausted. Bounded worker batches and request limits are examples. An unlimited queue of in-memory promises can consume memory faster than the database can complete them.
Load testing is an extension that needs a defined workload and environment. A credible result reports request mix, concurrency, latency distribution, errors, and the limiting resource. The API integration suite proves behavior, not a maximum supported user count.
Read pool settings in Read api/src/db.ts, task queries in Read api/src/tasks.ts, and worker batching in Read api/src/jobs.ts.
Find the resource that limits useful work. Pagination, short transactions, and bounded concurrency often matter before additional replicas or caches.
Does doubling the pool size always double throughput?
No. More concurrent queries can increase contention or exhaust Postgres resources. Measure the workload and database behavior before changing the connection budget.