Build fluency in the vocabulary of storing many related projects inside a single version-controlled repository.
0 / 5 completed
1 / 5
At standup, a dev mentions storing many separate projects, each with its own build and deployment, inside a single version-controlled repository instead of splitting each project into its own repository. What is this repository structure called?
A monorepo is exactly this: a monorepo stores many separate projects, each potentially with its own build and deployment pipeline, inside a single version-controlled repository, instead of splitting each project into its own separate repository, often called a polyrepo. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This one-repository-for-many-projects structure is exactly why a monorepo lets a single commit atomically update a shared library and every project that depends on it together.
2 / 5
During a design review, the team adopts a monorepo for a shared library and its many consuming services, specifically because a single commit can update the library and every consumer's usage of it together, atomically, in one review. Which capability does this provide?
A monorepo here provides atomic, cross-project changes in a single commit, since the shared library and every consumer live in the same repository and can be updated together instead of needing separate, coordinated commits across many repositories. Splitting the library and its consumers across separate repositories means a breaking change requires opening and merging multiple pull requests in careful sequence, with a real risk of a consumer being left on a mismatched version in between. This one-commit-updates-everything behavior is exactly why teams with tightly coupled shared code often choose a monorepo.
3 / 5
In a code review, a dev notices a breaking change to a shared library requires opening and merging five separate pull requests across five separate repositories in careful sequence, with consumers left on a mismatched library version in between, instead of updating the library and its consumers together in one repository. What does this represent?
This is a missed monorepo opportunity, since keeping the shared library and its consumers in one repository would let a breaking change update everything together atomically instead of requiring five separately sequenced pull requests. A cache eviction policy is an unrelated concept about discarded cache entries. This five-repository-sequencing pattern is exactly the kind of coordination overhead a reviewer flags once a shared library and its consumers change together often.
4 / 5
An incident report shows two consuming services broke in production because they were left on a mismatched version of a shared library during a multi-repository, multi-pull-request rollout, instead of the library and its consumers being updated together atomically. What practice would prevent this?
Adopting a monorepo lets a breaking change update the shared library and its consumers together in one atomic commit, eliminating the mismatched-version window. Continuing to roll out breaking changes across separate repositories with multiple sequenced pull requests regardless of how often consumers end up on a mismatched version in between is exactly what caused the outage described in this incident. This atomic, single-repository approach is the standard fix once a shared library's consumers are confirmed tightly coupled to its version.
5 / 5
During a PR review, a teammate asks why the team reaches for a monorepo instead of a polyrepo, given that a polyrepo gives each project full independence over its own release cadence. What is the reasoning?
A monorepo makes cross-project, atomic changes far easier at the cost of needing shared tooling to build and test only the affected projects at scale, while a polyrepo gives each project full release independence but makes a single breaking change across many projects require coordinating separate pull requests in sequence. This is exactly why teams with tightly coupled shared code often choose a monorepo, while teams with truly independent projects often prefer a polyrepo.