For sure, that's a factor that should be taken into account when deciding what to split and how. But monoliths always have completely unrelated things bunched u

For sure, that's a factor that should be taken into account when deciding what to split and how. But monoliths always have completely unrelated things bunched up in a single codebase, storage etc etc etc. Eg, in our case, there's simply no reason why we should have a single monolith service that has both our b2b partners user profiles and, I don't know, internal staff vacation hours? They have nothing to do with each other, have vastly different load profiles, tolerance for failure etc etc.