Design Monorepo CI

Problem Statement: Monorepo CI at Scale

Google TAP, Meta's stacked diffs, and Nx/Turborepo all converge on partial verification: only rebuild and retest what the dependency graph says changed. Your interview design is the control plane that turns a git diff into a minimal task DAG, fans work to ephemeral runners, and promotes signed artifacts only after merge gates pass.

Treat CI as a graph scheduler over workspace projects, not a single Jenkinsfile per repo.

For Problem Statement: Monorepo CI at Scale, anchor every decision to measurable outcomes: affected task count, cache hit ratio, queue wait, or dollars per vCPU-minute. Companies like Google, Meta, and Nx set the bar for partial monorepo CI—your design should generalize their patterns into a coherent control plane.

Quant anchors (state aloud)

• 8k engineers, ~120 projects, ~600 open PRs, ~2.5k pipeline runs/day peak.
• Median PR CI 22m → 6m when 75% remote task cache hits and affected closure is accurate.
• Control plane <500 QPS; logs ~7.5MB/s ingest; CAS egress bursts ~4.2GB/s on toolchain bumps.

Operational drill

When Problem Statement: Monorepo CI at Scale dependencies degrade, shed discretionary PR jobs first, protect default-branch merge queue, and expose a single timeline keyed by pipeline_run_id. Never promote unsigned artifacts—rebind to last cosign-verified digest.

Mechanism checklist

1. Affected closure — affected-project closure, transitive dependents, and trunk protection.
2. Task graph execution — ready tasks when upstream outputs exist or cache hits.
3. Hermetic cache keys — hash inputs + toolchain, not branch names.
4. Merge-safe gates — blocking tasks complete on merge group SHA.

Pitfall to avoid

running npm test at repo root on every PR.

How to open this one

The framing that lands for monorepo CI is affected-target computation: a commit must trigger only the builds and tests for the code it actually touches, computed from the dependency graph, or CI time explodes as the repo grows. Lead with change-based test selection plus a remote cache, and the failure story that proves it: a shared library change quietly affects 200 services, so the graph must be correct or you either over-test (slow) or under-test (ship a break). That shows you understand monorepo CI scales by precision, not by adding runners.