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.

Practice

1. What is a key advantage of using a mono-repo for microservices development?

easy

A. All code is stored in one place, simplifying code sharing and testing

B. Each microservice has its own separate repository for independent deployment

C. It forces teams to work in isolation without code conflicts

D. It automatically scales services without manual configuration

Solution

1. Step 1: Understand mono-repo structure

   A mono-repo stores all microservices code in a single repository, making it easier to share code and run tests across services.

2. Step 2: Compare with multi-repo

   Multi-repo keeps code separate per service, which is not the case here.

3. Final Answer:

   All code is stored in one place, simplifying code sharing and testing -> Option A

4. Quick Check:

   Mono-repo = single repo for all code [OK]

Hint: Mono-repo means one repo for all code [OK]

Common Mistakes:

• Confusing mono-repo with multi-repo
• Thinking mono-repo isolates teams
• Assuming mono-repo auto-scales services

2. Which of the following is the correct way to describe a multi-repo setup?

easy

A. Each microservice has its own separate repository

B. All microservices share a single repository

C. Microservices are merged into one large service

D. Repositories are automatically synced without manual control

Solution

1. Step 1: Define multi-repo

   Multi-repo means each microservice lives in its own repository, allowing independent development and deployment.

2. Step 2: Eliminate incorrect options

   Options B and C describe mono-repo or monolith, and D is not a standard feature.

3. Final Answer:

   Each microservice has its own separate repository -> Option A

4. Quick Check:

   Multi-repo = separate repos per service [OK]

Hint: Multi-repo means multiple repos, one per service [OK]

Common Mistakes:

• Mixing multi-repo with mono-repo
• Thinking multi-repo merges services
• Assuming automatic syncing between repos

3. Consider a team using a mono-repo for 5 microservices. Which of the following is a likely outcome when updating a shared library used by all services?

medium

A. The update must be manually copied to each service's separate repo

B. The update causes all services to stop working until redeployed

C. All services can immediately use the updated library from the single repo

D. Only one service can use the updated library at a time

Solution

1. Step 1: Understand shared code in mono-repo

   In a mono-repo, shared libraries are stored once and accessible by all services immediately after update.

2. Step 2: Analyze options

   The update must be manually copied to each service's separate repo describes multi-repo behavior. Options B and C are incorrect assumptions about usage and downtime.

3. Final Answer:

   All services can immediately use the updated library from the single repo -> Option C

4. Quick Check:

   Mono-repo enables shared updates instantly [OK]

Hint: Mono-repo shares code updates instantly [OK]

Common Mistakes:

• Assuming manual update per service in mono-repo
• Thinking only one service can use update
• Believing updates cause downtime automatically

4. A team using multi-repo faces frequent integration issues because services depend on shared code. What is the most likely cause?

medium

A. Multi-repo automatically merges conflicting changes causing errors

B. Mono-repo forces all services to use outdated code

C. Using multi-repo disables version control

D. Shared code changes are not synchronized across separate repositories

Solution

1. Step 1: Identify multi-repo challenges

   In multi-repo, shared code updates must be manually synchronized, or services may use incompatible versions.

2. Step 2: Evaluate incorrect options

   Multi-repo automatically merges conflicting changes causing errors is false as multi-repo does not auto-merge. Mono-repo forces all services to use outdated code is about mono-repo. Using multi-repo disables version control is incorrect about version control.

3. Final Answer:

   Shared code changes are not synchronized across separate repositories -> Option D

4. Quick Check:

   Multi-repo needs manual sync of shared code [OK]

Hint: Multi-repo needs manual sync for shared code [OK]

Common Mistakes:

• Blaming mono-repo for multi-repo issues
• Thinking multi-repo auto-merges conflicts
• Assuming multi-repo disables version control

5. Your company plans to scale from 3 to 50 microservices with multiple independent teams. Which repository strategy best supports independent team workflows and reduces merge conflicts?

hard

A. Use a mono-repo to keep all services in one place for easier testing

B. Use a multi-repo so each team manages their own service repository independently

C. Merge all microservices into a single monolithic repo to simplify deployment

D. Use a hybrid repo where all services share one repo but teams have separate branches

Solution

1. Step 1: Analyze scaling needs

   With many services and teams, independent repositories reduce merge conflicts and allow teams to work autonomously.

2. Step 2: Compare options

   Mono-repo (A) can cause conflicts at large scale. Monolith (C) loses microservices benefits. Hybrid (D) still risks conflicts on shared branches.

3. Final Answer:

   Use a multi-repo so each team manages their own service repository independently -> Option B

4. Quick Check:

   Multi-repo suits many teams and services [OK]

Hint: Multi-repo scales better for many teams [OK]

Common Mistakes:

• Choosing mono-repo for large independent teams
• Confusing monolith with microservices
• Thinking hybrid branches fully isolate teams