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

Design: Code Repository Strategy for Microservices

Design the repository structure and management approach for microservices codebase. Exclude detailed CI/CD pipeline design and deployment infrastructure.

Functional Requirements

FR1: Support development of multiple microservices by different teams

FR2: Enable easy code sharing and reuse across services

FR3: Allow independent deployment and versioning of microservices

FR4: Maintain code quality and consistency across the organization

FR5: Support scalable CI/CD pipelines

FR6: Provide clear access control for different teams

Non-Functional Requirements

NFR1: Must handle up to 100 microservices

NFR2: Support up to 50 concurrent developers

NFR3: CI/CD pipeline latency should be under 15 minutes for builds

NFR4: Availability of repository access should be 99.9%

NFR5: Support branching and merging strategies without conflicts

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Version control system (e.g., Git)

Build and CI/CD pipelines

Code sharing and dependency management

Access control and permissions

Branching and merging strategies

Code review and quality tools

Design Patterns

Monorepo pattern

Multirepo pattern

Feature branching

Trunk-based development

Dependency versioning

Access control models

Reference Architecture

                    +---------------------+
                    |    Developers       |
                    +----------+----------+
                               |
          +--------------------+--------------------+
          |                                         |
  +-------v-------+                         +-------v-------+
  |   Mono-repo   |                         |  Multi-repo   |
  | (Single repo) |                         | (Multiple repos) |
  +-------+-------+                         +-------+-------+
          |                                         |
  +-------v-------+                         +-------v-------+
  | CI/CD Pipeline|                         | CI/CD Pipeline|
  +---------------+                         +---------------+

Components

Version Control System

Git

Store and manage source code for microservices

Mono-repo

Single Git repository

All microservices code in one repository for easy code sharing and atomic changes

Multi-repo

Multiple Git repositories

Separate repository per microservice for independent versioning and deployment

CI/CD Pipeline

Jenkins/GitHub Actions/GitLab CI

Automate build, test, and deployment processes

Access Control

Git permissions and branch protections

Control who can read or write to repositories or branches

Dependency Management

Package managers (npm, Maven, etc.)

Manage shared libraries and versions across microservices

Request Flow

1. Developer clones the mono-repo or relevant microservice repo(s).

2. Developer makes code changes locally.

3. Developer pushes changes to the repository.

4. CI/CD pipeline triggers build and tests for affected microservices.

5. If tests pass, code is merged and deployed independently or together depending on repo strategy.

6. Shared code updates in mono-repo are immediately available to all microservices.

7. In multi-repo, shared code updates require version bumps and dependency updates in each microservice.

Database Schema

Not applicable as this design focuses on code repository structure and management.

Scaling Discussion

Bottlenecks

Mono-repo can become very large, slowing down cloning and CI builds.

Multi-repo can cause dependency version conflicts and harder code sharing.

CI/CD pipelines may become slow with many microservices in mono-repo.

Access control is more complex in mono-repo due to shared repository.

Coordination overhead increases in multi-repo when updating shared libraries.

Solutions

Use shallow clones and sparse checkouts to speed up mono-repo operations.

Implement incremental and parallel builds in CI/CD pipelines.

Use automated dependency versioning tools to manage multi-repo shared code.

Apply fine-grained access controls and branch protections in mono-repo.

Establish clear versioning and release policies for shared libraries in multi-repo.

Interview Tips

Time: Spend 10 minutes discussing requirements and constraints, 15 minutes comparing mono-repo and multi-repo approaches, 10 minutes on scaling challenges and solutions, and 10 minutes on trade-offs and recommendations.

Explain the trade-offs between mono-repo and multi-repo clearly.

Discuss how team structure and deployment frequency influence repo choice.

Highlight impact on CI/CD pipelines and developer productivity.

Mention strategies to mitigate scaling issues for each approach.

Show understanding of access control and dependency management challenges.

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