Scaling the Wrong Layer

Adding capacity is only useful when it is added to the constrained resource. Otherwise the extra capacity can increase pressure elsewhere.

Capacity is not a property of a system in the abstract. It belongs to a resource under a workload.

That sounds obvious, but many scaling decisions begin with a visible symptom—API latency, queue growth, CPU—and jump directly to the component nearest that symptom.

A better sequence is:

identify where work is waiting;
identify which resource controls that wait;
determine whether demand can be reshaped before capacity is added;
compare the operational cost of scaling with architectural alternatives.

This prevents a common failure mode: adding application capacity while increasing pressure on an already constrained database, broker, or downstream API.