Comparisons
Two tools, two questions. Neither column wins — what decides is which question you actually have in front of you.
Add capacity vs Fix the bottleneck
Both are legitimate. Adding capacity buys time and works only when the thing you add is the thing that is constrained; fixing the bottleneck is cheaper forever but slower to land. The failure is choosing without measuring which resource is actually constrained.
Right now, during an incident, when the constrained resource is one you can buy
Efficiency — you can scale a wasteful system indefinitely and pay for it forever
Linear and permanent spend; often no code risk
"Can we survive today?"
Anything that will still be running next quarter
Urgency — a profile-and-refactor is not an incident mitigation
Engineering time plus deployment risk; occasionally a redesign
"Why does this cost what it costs?"
| Dimension | Add capacity | Fix the bottleneck |
|---|---|---|
| Works when | The added resource is the constrained one | You have measured which resource is constrained |
| Fails when | The bottleneck is a lock, a pool, or someone else's API | The building is on fire |
| Leaves behind | A bigger bill and the same shape | A system with a different bottleneck |