You have to make the change to service A and B, and then test both and deploy both. You haven't saved any time or effort in a monorepo.
A library needs updating, you still have to update it and then test and deploy every service that relies on it independently. Again you haven't saved any time or effort. In fact you've made it worse, because if those services are maintained by different people, you just forced them to test and deploy on your timeline and priority, not theirs. You actually made the coordination problem worse.
I haven’t worked at a Big Tech monorepo place, but I hope/assume that in the service dependency case, you would touch both in one changeset and the deploy tooling understands the dependency tree and orders the deployments correctly. Without that i agree its the polyrepo approach just with all PRs in the same repo instead of multiple.
In the library scenario, I know tooling like bazel ensures that’s one changeset, not 3+. Tests run for both the changed library and all consumers of it in the same pass. You’re right that it might loop in others for review who weren’t expecting it, but i think that’s the same in a polyrepo approach.
The big thing about monorepos in this case is making a change atomic across a set of projects. Multirepos can't do this 99% of the time and often add a lot more procedure to something close. It's inherently async.
> The big thing about monorepos in this case is making a change atomic across a set of projects.
The thing microservices is supposed to solve is eliminating the need to make atomic changes across services. There is an inherent overhead in doing that, like making your service support both new and old APIs as long as any service exists using the old API. This is the cost of microservices.
The world isn't just backend. There are mobile projects, games, native desktop apps which act together as a suite and web frontends. Also microservices bring up their own host of issues and extra labor. Both are essentially the semantic versioning library update problem, and when you need to propagate a breaking change it create a whole bunch more labor that is significantly reduced in a monorepo vs. a multirepo/microservice world.
The tradeoff is you need to invest into repo scaling, much like a backend service that needs to invest in scaling itself too.
You have to make the change to service A and B, and then test both and deploy both. You haven't saved any time or effort in a monorepo.
A library needs updating, you still have to update it and then test and deploy every service that relies on it independently. Again you haven't saved any time or effort. In fact you've made it worse, because if those services are maintained by different people, you just forced them to test and deploy on your timeline and priority, not theirs. You actually made the coordination problem worse.