very true! which is why i think it usually is a good idea to analyze how you could split up your application into more or less discrete subsystems/"services". that way it becomes easier to react to bottlenecks in the subsystems instead of having to operate on the whole system.
ideally you design your system like that in the beginning but usually you grow and find out the harder way... step by step.
still there are a couple of things that are "always (about) the same": for example do session mangagement or logging/sitestats usually put quite a bit more write load (INS/UPD/DEL) on a system than other parts of a system.
so if your product grows the write stress these subsystems/functionalities put on a system on the one hand and the read load from other subsystems on the other hand make it hard to optimize your db/storage systems because they have quite contrary I/O needs.
if you have separate subsystems that run as discrete services with their own API it becomes much easier to put out a fire that breaks out due to growth or load spikes.
so to add to the comment by moe: "you scale applications" - and you get into a better position to do so if you design your applications in a way that they are composed of seperate subsystems that communicate via apis.