Earlier quoted context omitted.
To what end? To support that 1:10000 transaction that takes the most time and needs the most scaling? Just burn a wad of $20s, that will be easier.
To support that 1:10000 transaction that takes the most time and needs the most scaling? Done in the most naive way possible (just adding more servers to one giant pool) yes, it's as ineffective as you say. What can be effective is segregating resources so that your 1:10000 transaction is isolated so that it doesn't drag down everything else. Imagine: - requests to api.foo.com go to one group of servers - requests to…
Importing code paths that are never executed in a service is a security risk at best, a development/management nightmare on average, or an application crippling architectural decision at worst, especially when working with large monoliths. That is not a smart trade off - I would not recommend this pattern unless the cost to break off is so exorbitant that this would be your only choice.