Mono-repo vs multi-repo in Microservices - Scaling Approaches Compared

Scalability Analysis - Mono-repo vs multi-repo

Growth Table: Mono-repo vs Multi-repo

Scale	Mono-repo	Multi-repo
100 developers	Single repo manageable, fast code sharing, simple CI/CD	Multiple repos manageable, clear service boundaries, moderate overhead
10,000 developers	Repo size grows large, slower tooling, complex merges, CI/CD bottlenecks	Repos isolated, easier parallel work, complex dependency management
1 million developers	Practically impossible, tooling and infrastructure break down	Highly scalable, but requires strong governance and automation
100 million developers	Not feasible	Not feasible, but conceptually multi-repo scales better with automation

First Bottleneck

In a mono-repo, the first bottleneck is the version control system and CI/CD pipeline. As the repo grows, operations like cloning, branching, and merging slow down. The build and test processes become longer and consume more resources.

In a multi-repo setup, the bottleneck is dependency management and integration testing. Coordinating changes across many repos can cause delays and complexity.

Scaling Solutions

• Mono-repo: Use advanced version control tools optimized for large repos (e.g., Git with partial clone, sparse checkout). Implement distributed CI/CD pipelines with caching and incremental builds. Use code ownership and modularization to reduce conflicts.
• Multi-repo: Automate dependency updates and integration testing with tools like dependency bots and CI orchestration. Use clear API contracts and semantic versioning. Employ repository management platforms to streamline workflows.
• Both: Employ strong governance policies, automated testing, and monitoring to maintain code quality and deployment speed.

Back-of-Envelope Cost Analysis

Assuming 1000 developers working concurrently:

• Mono-repo: Large repo size (tens to hundreds of GB), high network bandwidth for cloning (~100 MB/s peak), CI servers need to handle thousands of builds daily, storage for build artifacts in TBs.
• Multi-repo: Many smaller repos (few GB each), less network per repo but more total repos, CI servers handle many smaller builds, storage distributed but similar total size.

Network bandwidth and storage scale with repo size and number of builds. Efficient caching and incremental builds reduce costs.

Interview Tip

Structure your scalability discussion by:

1. Defining the scale and team size.
2. Explaining the pros and cons of mono-repo and multi-repo at that scale.
3. Identifying the first bottleneck for each approach.
4. Proposing concrete scaling solutions tailored to the bottleneck.
5. Discussing trade-offs in complexity, developer experience, and operational overhead.

Self Check

Your version control system handles 1000 commits per hour. Your team grows 10x. What do you do first?

Answer: For mono-repo, optimize tooling with partial clones and incremental builds or consider splitting into multiple repos. For multi-repo, automate dependency updates and improve CI orchestration to handle increased integration complexity.

Key Result

Mono-repo works well for small to medium teams with fast code sharing but faces tooling and CI bottlenecks at large scale; multi-repo scales better for very large teams but requires strong automation for dependency and integration management.