Writing

The coordination tax in a polyrepo estate

I think of a polyrepo estate as a distributed system where each repository is a separate database. Each repository has its own owners, history, and release rhythm. That framing makes the cost structure visible. When a change needs to span repositories, I am no longer making a simple local edit. I am coordinating a transaction across ownership domains, backlogs, release trains, and access controls. The work has to move through multiple queues, and each boundary adds a chance for delay or misunderstanding.

In database terms, a commit that touches two repos behaves like a two-phase commit. I prepare changes in both places, then I coordinate the final commit across both. More participants means more latency and more failure modes. If one repo is held up by review or release constraints, the whole change stalls. That coordination tax does not appear as a line item in a sprint plan, but it is real and recurring. It shows up as slower delivery, more meetings, and a heavier cognitive load for engineers who must keep multiple codebases and conventions in their heads.

A monorepo changes the equation. It is like consolidating those separate databases into one database with well-defined schemas. When I make a change that touches three modules, it becomes a single local transaction. I edit, run the relevant tests, and commit. Reuse stops being a service boundary I have to negotiate and starts being a join I can simply use. AI tooling benefits as well: when the whole codebase is indexable in one place, the tools can spot patterns and generate cross-cutting changes with far less friction than they could across a scattered estate.

But a monorepo is not free. I still need strong build tooling, fine-grained ownership, and access controls. Without those, the single database becomes a big ball of mud. A large codebase can turn into a tangle if anyone can change anything and builds are slow or flaky. The size and complexity of the codebase do not go away; they get concentrated. The discipline does not disappear; it moves. I trade cross-repo coordination for internal build and ownership coordination.

That is why I do not think the decision should be driven by ideology. Some teams are better served by polyrepos, especially when ownership is genuinely independent and release cadences diverge. Others will benefit from the local-transaction nature of a monorepo. The business case should rest on measured coordination work: how much time goes into cross-repo reviews, release alignment, duplicated implementation, and waiting on access or ownership changes. If that recurring tax is high, a monorepo may be worth the investment. If it is low, the cost of migration and added tooling may not justify the move. I found the article The Coordination Tax in Your Software Estate to be a useful articulation of this trade-off.

Originally covered at differentshelf.com ↗