That's not what makes a distributed monolith, IMO. Or to put it differently, it's not what makes a "monolith" be equal to "bad" in people minds. You want to avo

That's not what makes a distributed monolith, IMO. Or to put it differently, it's not what makes a "monolith" be equal to "bad" in people minds. You want to avoid the badness, don't want to avoid the label. So, what is bad about a monolith? The complexity. Coupling of unrelated things; because it's simple to do so, because it's right there next to you and you know how it's implemented and what it performs, so you do thing A in component X knowing/relying on the fact that component Y will do the thing B, because that's how it's implemented (not because it's inherent unavoidable business logic). How do you end up with a distributed monolith? E.g. assume that microservice B will call microservice C only after you (i.e. microservice A) had a chance to call C first. Yes your code is distributed, but you don't get the benefit of logic segregation between the modules - you just get all the downsides of distributed systems. Do note that my scenario requires no shared code or library. Not sharing code doesn't save you from the distributed monolith - careful thought does.