The pitch I often hear with monorepos is “When you change your service/library/whatever, you can simultaneously change all of the clients of that library/service/whatever in one PR”. The problem is a PR is not a release - just because the code in the repo is up to date doesn’t mean the code in production is. So, for example, if your service changes to require an extra parameter in the API, sure, you can update all of the clients of that API to provide that extra parameter, but that still requires them to be built & released as well - just updating the code doesn’t actually fix the deploy/release coordination problem.

Short version, you’re right, coordinating releases with feature flags, branches, etc. solves this problem, but it solves the problem in a multi-repo world too, and a monorepo doesn’t obviate the need for those solutions as many of its proponents seem to suggest.

There are probably legitimate uses for monorepos, but an awful lot of people seem to position them as a silver bullet that lets developers stop having to worry about coordination in a multi-service world, and that’s just not how it works out.

I agree that it doesn't improve things at the service interface level. What I have found is that I often have several internal libraries, and a monorepo ensures that I know if a change to my library breaks another service because they're all in one build. Keeping things consistent across services is very useful in my experience.

The issue comes if you are communicating between different binaries (for example, RPC requests or message handlers). Just because you can change the code atomically doesn't mean you can deploy the client and server atomically.

As someone pointed out though, proto mitigates a lot of this.