Monorepo Strategy Vocabulary Exercises

1 / 5

An engineering team is evaluating monorepo vs. polyrepo for their new platform.

What is the PRIMARY benefit of a monorepo for a large engineering organisation?

Monorepo vs. polyrepo — the key architectural trade-off:

Monorepo benefit	Explanation
Atomic cross-project changes	1 PR updates API + all consumers simultaneously
Single source of truth	All code at the same version
Shared tooling	Consistent linting, testing, CI config

Trade-offs: CI must scale (affected commands), Git performance at large scale, access control complexity. Key vocabulary: atomic cross-project change, single source of truth, affected build, monorepo vs. polyrepo trade-off.

2 / 5

An Nx monorepo uses affected:build in CI.

What problem does the "affected" concept solve in monorepo tooling?

Affected builds — incremental CI for monorepos:

Without affected	With affected commands
All 500 packages built on every PR	Only changed packages + their consumers
CI takes 45 minutes	CI takes 3 minutes for typical PR

Monorepo tool builds a dependency graph → determines impact of changes. Tools: Nx, Turborepo, Bazel. Key vocabulary: incremental build, affected packages, dependency graph, task orchestration, caching (remote cache).

3 / 5

An architect says: "The monorepo uses Bazel for hermetic builds."

What does "hermetic" mean in a Bazel/build system context?

Hermetic build = same inputs → same outputs, always:

Hermetic	Non-hermetic
Builds only use declared inputs	Build reads system Python version implicitly
Identical output on any machine	Different output on CI vs. local
Remote cache key = input hash → cache hit	Cache key unreliable, cache miss on every build

Key vocabulary: build determinism, input declaration, remote cache hit, reproducible build, Bazel sandbox.

4 / 5

A principal engineer explains: "The monorepo has a CODEOWNERS-based module ownership model."

What governance problem does module ownership in a monorepo address?

Module ownership in monorepos — governance at scale:

Without ownership	With CODEOWNERS
Any engineer can silently change payments logic	`packages/payments/` requires `@payments-team` review
No accountability for module quality	Clear maintainer for each domain boundary

Key vocabulary: domain ownership, cross-boundary change review, module maintainer, stewardship in monorepos.

5 / 5

An architect says: "We migrated from monorepo to polyrepo because the monorepo wasn't scaling."

Which specific scaling challenge most commonly drives monorepo → polyrepo migrations?

Monorepo scaling challenges that drive migration:

Challenge	Mitigation (before migrating)
Slow git operations (clone, status)	Sparse checkout, partial clone
All builds triggered by unrelated changes	Affected commands, remote caching
Difficult per-service access control	CODEOWNERS + module boundaries

Key vocabulary: git at scale, sparse checkout, VFS for Git, polyrepo access control, scale-driven migration.