Quais são as estratégias monorepo vs polyrepo?

Question

Accepted Answer

**Monorepo** (um repositório para muitos projetos/serviços) e **polyrepo** (um repositório separado por projeto) são duas estratégias para organizar código em múltiplos projetos. Cada uma possui trade-offs significativos que afetam colaboração, tooling e escalabilidade — entender essas estratégias informa decisões arquitetônicas importantes.

## Monorepo — um repositório para tudo

```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 — um repositório por projeto

```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.
```

## Escolhendo

```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.
```

## Por que isso importa

Entender as estratégias monorepo vs polyrepo é conhecimento valioso de nível sênior para **tomar decisões arquitetônicas sólidas sobre organização de código**, uma escolha significativa com implicações amplas, portanto útil para papéis sênior/arquiteturais.

As duas abordagens — **monorepo** (muitos projetos em um repositório) e **polyrepo** (um repositório separado por projeto) — representam filosofias organizacionais fundamentalmente diferentes com trade-offs reais. As vantagens do **monorepo** (fácil compartilhamento de código e refatoração, **commits atômicos entre projetos** — mudar uma API e todos os seus consumidores juntos, tooling unificada e padrões, gerenciamento simplificado de dependências) o tornam poderoso para projetos fortemente acoplados com compartilhamento intenso de código, mas requer investimento significativo em **tooling de escalabilidade** (Nx, Turborepo, Bazel, sparse checkout, CI inteligente) para lidar eficientemente com repositórios grandes. As vantagens do **polyrepo** (propriedade e limites claros, ciclos independentes de versionamento e release, repositórios pequenos e focados, acesso granular) são apropriadas para projetos e times independentes, mas tornam o **compartilhamento de código mais difícil** (publicar/consumir packages, coordenação de versões) e **mudanças que afetam múltiplos projetos dolorosas** (coordenar PRs em muitos repositórios).

Entender esses trade-offs e como **escolher** (monorepo para projetos fortemente acoplados com compartilhamento de código dispostos a investir em tooling; polyrepo para projetos independentes e times com limites claros) reflete o julgamento arquitetônico esperado em níveis sênior — reconhecer que não há uma resposta universal e a escolha certa depende do acoplamento, escala, estrutura do time e investimento em tooling.

Como a organização de código em múltiplos projetos é uma decisão arquitetônica significativa afetando colaboração, tooling, escalabilidade e autonomia do time, e como entender os trade-offs monorepo/polyrepo informa essa escolha consequente, compreender as estratégias monorepo vs polyrepo é conhecimento valioso de nível sênior para tomada de decisões arquitetônicas, um tópico frequentemente debatido onde entender os trade-offs (em vez de favorecer dogmaticamente um deles) reflete o julgamento maduro esperado para papéis sênior que moldam como uma organização estrutura seu código.