TL;DR: For forty services that share libraries and frequently change together, I would consider a monorepo if the team can maintain dependency-aware CI. Independent repositories fit distinct access boundaries and separately managed components. Either layout needs compatible releases and evidence that patched artifacts actually reached production.
How to approach it
Ask which changes cross service boundaries and how often engineers coordinate them. Count the work around a recent shared-library update: finding consumers, changing code, testing compatibility and completing deployment. Repository count alone does not tell you which part is expensive.
A strong answer
A monorepo can put a library change and its consumer updates in one source commit. That helps review related changes together and test the affected source consistently. It does not make the services deploy atomically. Old and new application versions still overlap in production, so API and event compatibility need the same attention as they would across separate repositories.
Multiple repositories let teams manage source access and repository settings independently. Shared packages then need published versions and an update process. Automation can open dependency pull requests, run checks and track their disposition, so forty repositories need not mean forty manual edits. Breaking API changes and abandoned consumers still need engineering work.
Worked example: patching a library used by forty services
Assume a fictional fleet has forty consumers of a vulnerable parser. Thirty-four use its current major version, four use an older major version, and two are retained for infrequent batch processing. The security deadline is an exercise constraint, not a claim about a particular vulnerability.
In a monorepo, a source change can update the thirty-four compatible consumers together. The four older integrations still need an adapter or migration. The two batch services still need someone to build and deploy them before their next execution. A single-version dependency policy would require resolving these consumers before accepting the unified update; the repository itself does not impose that policy.
Across separate repositories, publish a patched package and create update changes for the compatible consumers. Track the older integrations as explicit exceptions with owners and mitigation deadlines. The same inventory must include dormant jobs. A repository search can find declarations, but the deployed artifact determines which library is running.
For either layout, track four states separately: source updated, required checks passed, patched artifact built, and production execution verified. The last state needs coverage across clusters, regions and scheduled workloads. A merged dependency update is only the first part of that sequence.
The operational cost I would compare
For a monorepo, inspect how CI identifies affected targets. The graph must include transitive dependencies and inputs such as shared compiler configuration. A path filter limited to the changed directory misses consumers of a shared package. Remote caches can reduce repeated builds, provided cache identity and writer permissions preserve trust. A small repository may start with full tests; adopt more sophisticated tooling when measured scale warrants it.
For separate repositories, inspect package publication, supported version ranges and ownership of cross-repository updates. Standard pipeline templates can reduce maintenance, but each consumer must adopt template fixes. Source isolation should not become an excuse for an unowned vulnerable dependency.
Given the shared-library scenario, I would pilot a monorepo with a few representative services if cross-service edits are a major recurring cost. I would measure affected-build accuracy and developer feedback time before proposing a fleet migration. If the existing repositories already have effective update automation and cross-service changes are rare, I would improve that process instead of moving source merely to change its layout.
What interviewers probe next
"How does a three-service change deploy?" Introduce compatible producers or consumers first, then switch behaviour once the required versions are present. Decide the order from the protocol change. A single source merge cannot replace this release sequence, and separate pull requests need not all merge in a fixed order when compatibility has been designed explicitly.
"Does CODEOWNERS isolate teams?" It routes review requests and can support required owner approvals through repository rules. It does not stop an authorised repository reader from seeing another directory. Use separate repositories when source must have different reader populations. GitHub describes code-owner review behaviour.
"How would you test an affected-build graph?" Compare selected targets against broader scheduled or sampled builds and investigate changes that escaped selection. Include shared configuration, generated files and dependency updates in the sample. A fast graph that silently omits consumers produces unreliable feedback.
"Does a monorepo require one release version?" No. Packages and services can retain independent versions. Choose dependency policy separately and document which version combinations remain supported during upgrades.
Common mistakes
Promising that one merged change patches every running service. Verify runtime versions, including infrequent workloads.
Assuming separate repositories create independent services. Shared databases, protocols and libraries can couple deployment regardless of source layout.
Choosing build tooling before measuring the work that is slow. Repository migration, cache infrastructure and dependency automation all carry ongoing maintenance costs.