I think you're right that this point is often overstated.

It does isolate each service from the scaling _issues_ of the others somewhat - if one service gets overloaded and crashes or hangs then other components are less likely to get brought down with it. In the best case if work is piling onto a queue and the overloaded component can be scaled fast enough even dependent components might not notice too much disruption.

Another advantage is that you can scale the hardware in heterogeneous ways - one part of the app may need fast I/O and the rest of the app might not care about disk speed much at all, so you can have different hardware for those components without overspending on the storage for the rest of the app. I think that's a minor advantage in most cases though.

A sort of in-between house is to have multiple copies of a monolith which are specialised through load balancing and/or configuration values and put onto different hardware, but all running the same code. Probably not that widely useful a technique but one that we've found useful when running similar long running tasks in both interactive and scheduled contexts.

Well, the hot path isn't necessarily the good behaviour one you would choose to scale.

e.g. login service DoS'd, but logged in users can continue using widget service, rather than it grinding to a halt as the login path heats up and consumes all resources.

back in the day we had a common micro service. it was called pgbouncer. Because database resources are limited it’s nice to have a stable consistent connection limited a set number of processes and then let the application monolith scale independently. Also, when you are scaling across multiple machines you don’t need all of the code of the monolith on every machine. i’ve heard about When amazon switched to a SaaS model, creating aws they were locked into a 32 bit monolith in which code was limited to a few GB and thus scaling resources independent was valuable. Was this useful? I am collecting data on if i’m polite, without snark and helpful.

You're assuming an app that scales linearly with hardware. That's very hard to engineer. That's in fact the problem we're trying to solve: The hardware's there but the app can't make use of it due to some contention somewhere.

?

If you scale a monolith you have to scale the whole thing.

You seem to be describing that a monolith is more efficient that a microservice in a non scaling situation, which is true, but I think you have missed the point on scaling.