This is a good overview of concerns for a monorepo implementation (which we are migrating to at Shopify).

I really think all these problems can be solved in a polyrepo world, especially if you’ve started your polyrepo structure with a few mandatory inspection/insertion points. I’ll expand on this in a future post.

The greatest power and biggest lie of the monorepo is that it is possible to make atomic commits across your entire codebase. While this is objectively true from a code perspective (you certainly can land a PR that, for example, renames a function across your entire codebase), this is not true from a deployment perspective, and this dangerous lie will cause incidents.

I feel like the monorepo is forcing a stateless model onto an inherently stateful (because it is so distributed in runtime/space) system and then backfilling support for that state management.

I also feel like the monorepo promises lower maintenance through reduced package ecosystem friction (e.g. federation is expensive, you can link directly to the package), but does it come at the cost of tighter coupling? We’ve seen that componentization reduces maintenance in the open-source setting.

Is a monorepo coding the volume instead of coding the perimeter?

Maybe monorepos attempt to paper over the fundamental distributed systems challenges rather than acknowledge and design around them. You can’t git-commit your way out of the CAP theorem, no matter how much tooling you build.

Maybe there’s a fundamental systems engineering truth: architectural decisions that work at the code level often break down at the operational level. The monorepo creates a false sense of atomicity that doesn’t survive contact with the distributed reality of deployment infrastructure. Atomic commits are an optimistic assumption in a distributed system.