Add capacity anywhere and the queue doesn't disappear. It relocates — usually somewhere less visible, and occasionally somewhere worse.
Five earlier cards, the same pattern every time. Five hundred threads against a hundred connections: the threads stopped waiting on CPU and started waiting on the pool. A bigger connection pool: the queue left the application and formed inside the database, where it costs more. Load shedding: we can't create capacity by agreeing to work, and refusing early moves the pain to whoever we refused. The hot partition: perfect distribution of data, perfect concentration of attention on shard 4. Backpressure: an unbounded queue doesn't absorb a mismatch, it postpones the moment we admit to one.
A system is a chain of stages, and only one of them is the constraint at any moment. Widen it and something else becomes the constraint immediately, by definition. The open question is whether we chose the next one deliberately or discovered it in production.
Which is the useful reframe for capacity planning: the work is less about removing the bottleneck than deciding where we would rather it sat.
Optimisation doesn't remove limits. It chooses which one we live with next.