Loading…
Design a CI/CD Pipeline for a Monorepo is a medium low-level design interview question covering operational design, devops, ci/cd, release engineering, deployment — the kind asked at FAANG (Facebook/Meta, Apple, Amazon, Netflix, Google) and AI-first companies like Anthropic, OpenAI, and Nvidia.
Design the build and delivery pipeline for a monorepo holding about 200 deployable services, worked on by a few hundred engineers who land several hundred commits a day. Services share libraries heavily. The main branch must stay releasable, and developers should not wait an hour for feedback. Decide what gets built and tested on each change, what runs before a merge and what runs after, and how an artifact reaches production.
That's it. No further details. This is intentional — your first job is to scope the problem by asking the right clarifying questions.
A design question where the constraint is developer time rather than user traffic, and the metric nobody states up front is how long a change takes to reach production. Anyone can draw build, test, deploy in a row. What is being assessed is whether the candidate notices that a monorepo makes the naive pipeline unusable — building everything on every commit means a one-line change waits behind two hundred services — and can describe how to build only what actually changed without ever shipping something untested. The second half is trust: a test suite that fails randomly is worse than no test suite, because a team that has learned to re-run red builds has stopped reading them.
Work through the Clarify phase by asking questions one at a time — just like a real interview.
Each answer reveals why that question matters and how it changes your design decisions.
Once you've clarified enough, unlock the full architecture, calculations, and trade-off analysis.
The constraint here is developer time rather than user traffic, and the number nobody states is how long a change takes to reach production. Building everything on every commit is tens of thousands of builds a day and makes a one-line change wait behind two hundred services, so the pipeline has to build only what could have changed. The critical detail is that selection comes from the build system dependency graph and not from which directories were touched: a path-based rule fails in the dangerous direction, because editing a shared library changes no service directory, so nothing is tested while everything is broken. Take the transitive closure of dependents, which requires hermetic targets with declared inputs, since an undeclared dependency is invisible to the selection. Content-addressed caching then makes the affected set affordable - every step keyed by a hash of its inputs, so unchanged work is fetched rather than rebuilt, with determinism as a hard precondition because anything leaking into the output that is not in the key makes the cache either useless or wrong. Test results cache on the same principle and that is often the larger saving. Verification is tiered, and it should be named as a risk decision rather than presented as free: fast targeted checks before merge because a human is blocked, expensive integration, end-to-end and performance suites after merge on main, with a real ownership and paging path or post-merge failures rot into advisory noise. Because changes arrive faster than a full cycle takes, a merge queue is required rather than optional - testing a pull request against the state of main when it was opened proves nothing about the state it lands in, and two individually-fine changes are how main breaks. The queue tests against the actual tip, speculatively batching several changes and bisecting to eject the culprit when a batch fails, because discarding whole batches collapses under retries during a busy period. Finally, build once and promote the same immutable artifact by digest through every environment; rebuilding per environment means the tested object and the shipped object are different things, and it breaks rollback, which needs the previous artifact to still exist rather than to be reproducible. Configuration stays outside the artifact so one digest runs everywhere. The last component is trust: blanket retries on flaky tests hide the flake rate, retry genuine intermittent bugs into silence, and train a team to re-run red builds, so measure per-test reliability and quarantine automatically with an owner and a deadline instead.
A full interview loop is more than one round. These are the others, each with what is on the site for it.