The Hook (The "Byte-Sized" Intro)
Google keeps billions of lines of code in a single monorepo. Netflix runs hundreds of separate repos. Both approaches work — but for different reasons. Monorepos make cross-project changes easy. Multirepos give teams autonomy. Choosing wrong doesn't break things immediately — it creates friction that compounds over months until refactoring becomes unavoidable.
📖 What is Monorepo vs Multirepo?
Two strategies for organizing code repositories: one large repo for multiple projects (monorepo) vs separate repos per project (multirepo).
Conceptual Clarity
Side-by-side comparison:
| Factor | Monorepo | Multirepo |
|---|---|---|
| Structure | One repo, many projects | One repo per project |
| Cross-project changes | ✅ Single commit | ❌ Multiple PRs |
| CI/CD | Complex (selective builds) | Simple (per-repo) |
| Access control | 🟡 Harder (code owners) | ✅ Per-repo permissions |
| Dependency sharing | ✅ Direct imports | ❌ Package publishing |
| Tooling | Needs Nx, Turborepo, Bazel | Standard Git |
| Repo size | Can grow very large | Stays small |
| Team autonomy | 🟡 Shared conventions | ✅ Independent choices |
Who uses what:
| Company | Strategy |
|---|---|
| Google, Meta, Twitter | Monorepo |
| Netflix, Amazon, Spotify | Multirepo |
| Many startups | Start monorepo → split later |
Real-Life Analogy
- Monorepo = One big warehouse with departments for clothing, electronics, and furniture. Easy to move items between departments, but the warehouse needs heavy-duty infrastructure.
- Multirepo = Separate specialty stores. Each runs independently, but coordinating a sale across all stores requires more effort.
Visual Architecture
Why It Matters
- Team velocity: Wrong structure creates friction in daily workflows.
- Scaling: Monorepos need specialized tooling at scale (Nx, Bazel).
- Onboarding: Monorepos are simpler to onboard (one clone, everything there).
- Migration: Switching later is expensive — choose thoughtfully upfront.
Code
# ─── Monorepo structure ───
# my-company/
# ├── apps/
# │ ├── web/
# │ └── mobile/
# ├── libs/
# │ ├── shared-ui/
# │ └── utils/
# ├── packages/
# │ └── api-client/
# └── package.json ← Workspace root
# ─── Monorepo tooling ───
# Nx: npx create-nx-workspace
# Turborepo: npx create-turbo
# Bazel: enterprise-scale builds
# ─── Multirepo structure ───
# github.com/team/web-app ← Separate repo
# github.com/team/mobile-app ← Separate repo
# github.com/team/shared-utils ← Published as npm package
# github.com/team/api-server ← Separate repo
# ─── Selective CI in monorepo ───
# Only build what changed:
# git diff --name-only HEAD~1 | grep "^apps/web/" && npm run build:webKey Takeaways
- Monorepo: One repo for all projects. Great for cross-project changes and shared code.
- Multirepo: Separate repos per project. Great for team autonomy and simplicity.
- Monorepos need specialized tooling (Nx, Turborepo, Bazel) at scale.
- There's no universally "right" answer — it depends on team size, dependencies, and workflow.
Interview Prep
-
Q: What are the pros and cons of a monorepo? A: Pros: atomic cross-project changes, easy code sharing, single CI/CD pipeline, simpler onboarding. Cons: repo size grows large, needs specialized build tooling, access control is harder, CI must be selective.
-
Q: When would you choose multirepo over monorepo? A: When teams need full autonomy (different tech stacks, release cycles), when projects have no shared code, or when repo size would become unmanageable. Multirepos work well when dependencies are published as packages.
-
Q: How do monorepos handle CI/CD efficiently? A: Using tools like Nx or Turborepo that detect which projects are affected by a change (via dependency graph analysis) and only build/test those projects — not the entire monorepo.