The choice between a monorepo and many repositories is argued as a matter of taste, and it is really a question about where you want to pay for coordination. Splitting code across repositories makes each one simpler to reason about and makes any change crossing them considerably harder. Keeping everything together inverts that. Neither is free, and the right answer depends on facts about your own team that you can check, rather than on what a large technology company published about its setup.
The strongest argument for a single repository is that a cross-cutting change stays atomic. Renaming an interface used by four services is one commit, one review and one pipeline run. In separate repositories the same change becomes a release, a version bump in each consumer, a sequence of dependent pull requests, and a window in which the system is half migrated and both versions must work. Teams rarely count that choreography as cost, because it does not feel like engineering, it feels like process.
The arguments against are real and mostly about tooling. Checkouts grow, naive continuous integration rebuilds everything on every change, and code search and editor performance degrade if nobody maintains them. All of these are solvable - path-based pipeline triggers, partial clones, build caching - but solvable means somebody owns them. If no one wants that job, a monorepo decays into a slow, irritating experience and the team blames the layout rather than the neglect.
The reason usually given for many repositories is team independence, and it deserves scrutiny. Independence is real when teams genuinely release on their own schedules to consumers they do not control. It is imaginary when four services are deployed together every Thursday by the same people. In the second case the repositories are not providing autonomy, they are providing extra steps, and the version numbers are ceremony because nothing ever runs a version other than the newest.
Some situations genuinely force separation. Code released publicly or under a different licence belongs on its own. Components with different access requirements, where a subset of engineers must not read the rest of the codebase, are cleaner apart. Acquired systems with their own history and build tooling are rarely worth merging. And a library consumed by external customers needs real versioning, because you cannot update your consumers.
The middle ground works better than either extreme argued in the abstract. A single repository with explicit ownership per directory, pipelines that run only what a change can affect, and clear internal boundaries gives most of the atomic-change benefit without the everything-rebuilds problem. Ownership matters more than layout: what hurts teams is not shared code, it is shared code with no owner.
The unfashionable position is that most teams below the size where a platform group exists chose many repositories by drift rather than decision - a service was started, it got a repository, the pattern repeated - and they pay a coordination tax every week without having decided to. If you cannot name the independence your repository boundaries are buying, they are probably not buying any.
