What are monorepo vs polyrepo strategies?

Question

Accepted Answer

**Monorepo** (one repository for many projects/services) and **polyrepo** (a separate repository per project) are two strategies for organizing code across multiple projects. Each has significant trade-offs affecting collaboration, tooling, and scaling — understanding them informs important architectural decisions.

## Monorepo — one repo for everything

```text
Many projects/services/libraries in a SINGLE repository:
  ✓ SHARED code/libraries easy to use and refactor (one place, atomic changes)
  ✓ ATOMIC commits across projects (change an API and all its consumers together)
  ✓ Unified tooling, versioning, CI; consistent standards; easy cross-project visibility
  ✓ Simplified dependency management (one version of shared code)
  ✗ Repo can get HUGE (needs scaling tooling — sparse checkout, build caching)
  ✗ Needs sophisticated build/CI tooling (Nx, Turborepo, Bazel) to be efficient
  ✗ Broad access; CI must be smart (only build what changed)
→ Used by Google, Meta, etc. (with heavy tooling investment).
```

## Polyrepo — a repo per project

```text
Each project/service/library in its OWN repository:
  ✓ Clear OWNERSHIP and boundaries; independent versioning/releases/CI
  ✓ Smaller, focused repos; granular access control; independent teams
  ✗ SHARED code is harder (publish/consume packages; version coordination)
  ✗ Cross-cutting changes span MANY repos (coordinate multiple PRs — painful)
  ✗ Potential inconsistency across repos (tooling, standards drift)
→ Common default; fits independent services/teams.
```

## Choosing

```text
MONOREPO → tightly-coupled projects, heavy code sharing, want atomic cross-project
  changes and unified tooling, willing to invest in scaling tooling
POLYREPO → independent projects/teams, clear boundaries, independent release cycles,
  simpler per-repo needs
→ No universal answer; depends on the org, coupling, scale, and tooling investment.
```

## Why it matters

Understanding monorepo vs polyrepo strategies is valuable senior-level knowledge for **making sound architectural decisions about code organization**, a significant choice with broad implications, so it's useful for senior/architectural roles.

The two approaches — **monorepo** (many projects in one repository) and **polyrepo** (a separate repository per project) — represent fundamentally different organizational philosophies with real trade-offs. **Monorepo** advantages (easy shared code and refactoring, **atomic cross-project commits** — changing an API and all its consumers together, unified tooling and standards, simplified dependency management) make it powerful for tightly-coupled projects with heavy code sharing, but it requires significant investment in **scaling tooling** (Nx, Turborepo, Bazel, sparse checkout, smart CI) to handle the large repository efficiently. **Polyrepo** advantages (clear ownership and boundaries, independent versioning and release cycles, smaller focused repos, granular access) suit independent projects and teams, but make **shared code harder** (publishing/consuming packages, version coordination) and **cross-cutting changes painful** (coordinating PRs across many repos).

Understanding these trade-offs and how to **choose** (monorepo for tightly-coupled, code-sharing projects willing to invest in tooling; polyrepo for independent projects and teams with clear boundaries) reflects the architectural judgment expected at senior levels — recognizing there's no universal answer and the right choice depends on coupling, scale, team structure, and tooling investment.

Since code organization across multiple projects is a significant architectural decision affecting collaboration, tooling, scaling, and team autonomy, and since understanding the monorepo/polyrepo trade-offs informs this consequential choice, understanding monorepo vs polyrepo strategies is valuable senior-level knowledge for architectural decision-making, a frequently-debated topic where understanding the trade-offs (rather than dogmatically favoring one) reflects the mature judgment expected for senior roles shaping how an organization structures its code.