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 o

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.