The repository layout question gets argued as a matter of taste and is really a trade between two costs. A single repository makes it easy to share code and change several services together, and hard to keep them independent. Many repositories make independence the default, and coordination expensive. Whichever you choose, you pay one of those bills.
The case for a monorepo is strongest when services change together. A change to an API and its three consumers is one commit, one review, one atomic merge - rather than four pull requests in four repositories that must land in the right order and cannot be reverted as a unit. Shared libraries need no publishing step, so a change to a utility is immediately visible to everything using it, along with any compile errors it causes. That last point is the real benefit: breakage is discovered at the moment of the change rather than weeks later when someone upgrades.
The cost is tooling. Without care, every pull request runs every test, which is slow and gets worse as the repository grows until people stop waiting for it. Making it viable requires build tooling that understands the dependency graph and runs only what a change affects, plus CI that can cache aggressively. That is a real investment, and monorepos adopted without it become slower to work in than what they replaced.
Separate repositories give clean ownership boundaries, independent release cadence and small fast pipelines by default. The cost lands on shared code: a change to a common library must be published, versioned and adopted by each consumer separately, and in practice consumers upgrade at different times, so several versions are live at once and a breaking change is discovered piecemeal. Coordinating a change across five repositories is the daily friction that eventually motivates people to propose a monorepo.
Team size is a reasonable heuristic. A handful of teams working on tightly related services usually benefit from one repository, because their changes genuinely cross boundaries. Many independent teams with genuinely independent products usually do not, and forcing them together creates coupling that did not exist. Note that the repository layout does not have to match the deployment architecture - a monorepo can contain independently deployed services, and that combination is common and works well.
Whatever you choose, the things that actually determine day-to-day quality are the same: a single command to get a working environment, a pipeline that gives a result within a few minutes, clear ownership of every directory, and a way to make a change across a boundary without a week of coordination. Teams that get those right are productive under either layout, and teams that do not are unproductive under both.
