Monorepo vs Polyrepo: What the Blast Radius Tells You

The answer to "monorepo vs polyrepo" is not a recommendation - it's a measurement. Specifically: what percentage of your features require changes across more than one service boundary?

If you don't know that number, you're making an infrastructure decision based on team preference rather than data. And in a 50-person engineering organization, that preference will cost someone a Sunday.

The keyword here is calculation. Both approaches impose costs. The question is which costs your organization can absorb better - the coordination tax of polyrepo or the tooling investment of monorepo.

PR Cycle Time Data Should Settle This. It Doesn't

Faros AI analyzed 320 engineering teams over 12 months and found that monorepo environments have a median PR cycle time of 19 hours. Polyrepo environments: 2 hours.

That is a 9.5x gap at the median. At the 90th percentile, the gap narrows to 8.6 days versus 5.5 days - but both tails are slow. The mean also narrows: 3.6 days monorepo, 2.8 days polyrepo.

The counterargument is well-established: monorepos have faster individual build times when caching works. A polyrepo team coordinating a cross-service change across five repositories with five separate CI pipelines and five separate CODEOWNERS sign-off requirements will not close a PR in two hours either.

The data captures cycle times for typical PRs, not worst-case cross-cutting changes. That distinction matters. Polyrepo teams quote their median (fast, because most of their PRs are isolated). Monorepo advocates quote the pain of coordinating across repos (also real, and documented in their worst-case PR tails). Both sides are right about different scenarios.

The data does not settle the debate. It describes the tradeoff more precisely than vibes do.

The Blast Radius You're Not Calculating

Here's what rarely makes the conference talk slides: in a monorepo, a broken shared dependency lands across every service that imports it, in the same commit, before anyone with downstream ownership has reviewed the change.

In a polyrepo, a broken package version breaks the services that upgrade it - but only when they upgrade it. The blast radius is deferred and bounded by consumer choice.

This matters for SLO-gated rollouts. A bad shared library in a monorepo does not give you a canary window. It gives you a cross-service blast radius in a single deploy event. Your error budget starts burning across multiple SLOs simultaneously before your rollout automation can detect the pattern and trigger a revert.

In a polyrepo, the rollout of a shared dependency change is sequential by nature. Service A upgrades and you watch its SLO. Service B upgrades three days later. The blast radius at any given moment is bounded by who has already adopted the change.

The question is not which structure is inherently safer - it's what your deployment primitive is. If your deployment unit is the service with its own SLO gate, polyrepo gives you natural isolation. If your deployment unit is the atomic feature change landing consistently across frontend, API, and background worker simultaneously, monorepo gives you that coordination without versioning drift.

Most teams shipping microservices have the first problem. Most teams shipping a tightly coupled product surface have the second.

Why Polyrepo Teams Hit a Coordination Wall at 50 Engineers

The coordination tax compounds. At 8 engineers, managing four repositories is annoying but feasible. At 50, it becomes a part-time job for several people.

Concrete signs that polyrepo coordination overhead has become structural:

• Your platform team maintains a shared-libraries repo that nobody has clear ownership of

• Versioning across services has drifted enough that bumping the shared library is a two-week project

• A new engineer cannot be productive without understanding which of your 23 repositories to clone first

• Security patches to shared dependencies require coordinated PRs across a dozen repos, with a tracking spreadsheet

None of these are invented pathologies. They are documented failure modes from teams who reached 80 engineers and looked back at their repo decisions with regret.

Polyrepo works when teams are genuinely independent - different release cycles, different tech stacks, different on-call rotations. When teams share enough code that a change in one service requires reasoning about three others, the isolation that polyrepo was bought for becomes the mechanism that makes coordination painful.

The organizational tell: count how many Slack channels exist specifically to coordinate cross-repo releases. If the answer is more than zero, you have already started paying the coordination tax consistently.

What Monorepos Actually Cost at the 95th Percentile

The P90 data from Faros AI is instructive: 8.6 days for monorepo PRs at the 90th percentile. That is not a slow team - it is the structural consequence of large cross-cutting changes requiring coordination across multiple code owners, broader CI matrices, and review cycles that span organizational boundaries.

Google has Bazel. Meta built Buck. Nx Cloud and Turborepo remote cache exist because the tooling investment to make a monorepo perform is not trivial. A monorepo at 200 engineers without affected-only build selection, distributed caching, and automated merge queues produces 45-minute CI runs on PRs that touch a shared utility function.

The tooling cost is real and routinely underestimated. Teams that successfully operate monorepos at scale have typically hired platform engineers specifically focused on that infrastructure. Retrofitting monorepo tooling onto a growing codebase while also shipping product is a drain that shows up in deployment frequency before it shows up in a post-mortem.

If your platform team is already stretched, adding monorepo tooling maintenance is a meaningful commitment - not a configuration choice.

The 30 Percent Rule High-Performing Teams Actually Use

A useful heuristic from teams that have made this decision deliberately: if more than 30% of your features require changes across multiple service boundaries, the coordination overhead of a polyrepo will eventually exceed the tooling investment of a well-run monorepo.

Below 30% - where most microservices organizations sit - polyrepo's isolation benefits usually outweigh the coordination tax. Cross-service changes happen, but not frequently enough to make shared tooling pay off faster than isolation does.

This is measurable. Pull your last six months of merged PRs and count how many required changes in more than one repository to ship a single user-facing feature. That ratio is your input. It will not be precise to a decimal, but it will be directional - and directional is enough to stop the debate from running on team preference.

A team with a 12% cross-service rate does not need a monorepo. A team at 38% and growing is paying coordination tax that will keep compounding.

How Rollout Strategy Changes the Calculation

There is a dimension of this decision that gets almost no coverage: your rollout primitive.

If you run percentage-based rollouts with SLO gates - shipping a feature to 5% of traffic, watching error budgets, then progressively expanding - your blast radius calculation changes depending on whether the feature spans one service or several.

In a polyrepo, a multi-service feature rollout requires coordinating the rollout state across services. Service A can be at 20% while Service B is still at 0%, creating inconsistent states that are genuinely hard to reason about under incident conditions. Feature flags help, but you are still managing cross-service flag state with no single source of truth for rollout progress.

In a monorepo with atomic commits, the feature lands consistently across services. The rollout can still be percentage-based at the infrastructure level, but the code is consistent from the moment the deploy happens. Your SLO gates fire against a coherent state.

Teams doing a lot of atomic multi-service features, running progressive rollouts with automated rollback on SLO breach, often find that monorepo's consistency eliminates an entire category of incident that polyrepo does not have a clean name for - the cross-service state divergence incident that looks like a bug but is actually a deployment coordination problem.

What the Post-Mortem Will Actually Say

Most engineering organizations end up on a hybrid that nobody calls a hybrid because it sounds like an architectural cop-out.

One or two monorepos for tightly coupled product surfaces. Separate repositories for genuinely autonomous services with independent deployment cycles, their own on-call rotation, and a team that has not needed to coordinate a shared library change in six months.

The signal to revisit your current setup:

• Cross-service change frequency has crossed 30% and CI runtimes are compounding

• You have hired platform engineers with capacity to invest in monorepo tooling

• A blast radius incident revealed that your polyrepo isolation was false - the services were sharing enough infrastructure that the isolation was providing comfort, not safety

The signal that the decision is fine for now:

• Teams are genuinely independent and coordination overhead is low

• Your worst incident was not caused by cross-service dependency drift

• Platform engineering capacity does not exist to maintain monorepo tooling without slowing product delivery

The post-mortem will tell you which of these you are actually living in. That document is usually more honest than the architecture decision record that preceded the system it describes.