Calling eachother at network level is still a dependency. (And even a build dependency if you use something like protobuff or other protocol description files)

A network dependency is not a build dependency. Protobuf files should be copy pasted, not referenced directly. Saying you need a single repo to build correctly for your network dependencies is like saying you cant use a third party system (aws, etc.) Without having a link to their code base.

Point is that when you want to do a change in the "API" (or call it "protocol"), you need to touch the different repositories and coordinate to use the right versions together.

About the copy/paste of protobuf files, it works but makes it more difficult to keep them in sync.

And I did not say you need a single repo. I'm saying the stated disadvantages of multi repo are real.

That’s the part about monorepos I can’t quite wrap my mind around - yes deploying a single large change to many different systems simultaneously is cool in theory, but how does it actually pan out? Deployment is never instant, so any system-to-system breaking changes would cause a short downtime while everything deploys. In the world I operate in, that’s absolutely not acceptable.

Not that you can’t still make your changes backwards compatible with themselves. But if I’m going to have to deploy everything in two steps anyway, what’s the point?

But... we do better things than microservices: https://github.com/7mind/slides/blob/master/02-roles/target/...

Read this, not worthwhile and OT.

> not worthwhile

Why so?

> and OT

Not at all. In both cases it's about roles.

It misses the point of microservices in the same way that posts titled 'sharding' instead talk about load-balancing.