Monorepo vs polyrepo strategies
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
The monorepo versus polyrepo decision changes fundamentally depending on the cost you are optimizing for: cross-cutting changes and dependency consistency, or team autonomy and build isolation.
Monorepo — atomic cross-cutting changes
- Renaming a field in a shared domain event consumed by eight services is one PR in a monorepo — the consumer changes compile, tests run, and the refactor merges atomically; in a polyrepo it requires eight coordinated PRs merged in dependency order
- Dependency versions are consistent across all services by definition — no service silently runs a different Jackson or Spring Boot version than the others, eliminating a class of subtle runtime incompatibility bugs
- The build tooling investment is real: Gradle composite builds, Bazel, or Nx are required to avoid rebuilding every service on every change; without incremental builds, a monorepo becomes slower with every service added
Polyrepo — team autonomy and isolated CI
- A payments team should not wait for the notifications team's failing test before merging a security patch — separate repositories give each team a closed CI system with independent build and deploy pipelines
- Service boundaries are explicit at the repository level; the coupling between teams is visible because it shows up as a versioned dependency, not an implicit shared file
- Renovate or Dependabot automates dependency version updates across repositories, reducing the manual coordination cost for keeping shared library versions aligned
The pragmatic middle ground
- Domain-grouped repositories organize related services together: the payments domain owns its API, worker, and shared library in one repo; the notifications domain owns its services in another
- Gradle composite builds let sibling projects reference each other as source dependencies rather than published artifacts — a library change triggers an immediate recompile of the consumer without a publish step
Draw repository boundaries along domain lines, not service lines. One repo per bounded domain, shared platform tooling in a separate repo that all domains consume.
Monorepo vs polyrepo strategies
Direct Answer
A monorepo stores all services and shared libraries in one repository, enabling atomic cross-service commits, easier refactoring, and unified tooling at the cost of slower CI and more complex build tooling. A polyrepo gives each service full autonomy and faster isolated pipelines at the cost of dependency versioning overhead and harder cross-service refactors. Most large Java organisations use a middle ground: a small number of repos grouped by domain or team ownership.
Check your understanding
Answer these without looking back at the article.
- How does Gradle's composite build feature support monorepo development?
- What is sparse checkout and how does it help with large monorepos?
- How would you configure CODEOWNERS to enforce team ownership in a Java monorepo?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.