Mono-repo vs multi-repo in Microservices - Architecture Trade-offs

Problem Statement

When multiple teams work on many microservices, managing code scattered across many repositories or a single repository can cause coordination failures. Without clear structure, teams face difficulties in code sharing, versioning, and deployment, leading to slower development and integration issues.

Solution

Mono-repo keeps all microservices' code in one repository, enabling easy code sharing and unified versioning. Multi-repo splits each microservice into its own repository, allowing independent development and deployment. Both approaches organize code to reduce conflicts and improve team productivity, but they do so with different trade-offs in coordination and tooling.

Architecture

Mono-repo

┌─────────┐ ┌─────────┐

↓

Repo A

(Service A)

The diagram shows mono-repo as a single repository containing multiple services, while multi-repo shows separate repositories for each service.

Trade-offs

✓ Pros

→

Mono-repo simplifies code sharing and refactoring across services with a single source of truth.

→

Mono-repo enables unified versioning and easier atomic commits affecting multiple services.

→

Multi-repo allows teams to work independently with isolated codebases and separate deployment cycles.

→

Multi-repo reduces repository size and complexity per service, improving clone and build times.

✗ Cons

→

Mono-repo can become very large, causing slower tooling and requiring advanced build systems.

→

Mono-repo needs strong governance to avoid conflicts and manage permissions across teams.

→

Multi-repo complicates cross-service changes and dependency management due to separate versioning.

→

Multi-repo requires more infrastructure to coordinate builds, tests, and deployments across repos.

Use mono-repo when teams are tightly coupled, need frequent cross-service changes, and have tooling to handle large repos (e.g., Google, Facebook scale). Use multi-repo when teams are autonomous, services have independent lifecycles, and you want clear ownership boundaries.

Avoid mono-repo if your codebase is small or teams are fully independent, as the overhead of managing a large repo may outweigh benefits. Avoid multi-repo if you need frequent atomic changes across services or unified versioning.

Real World Examples

Google

Uses a massive mono-repo to manage thousands of services, enabling easy code sharing and atomic cross-service changes.

Netflix

Uses multi-repo to allow independent teams to develop and deploy microservices autonomously with separate repositories.

Facebook

Employs a mono-repo to maintain a unified codebase for rapid development and consistent tooling across teams.

Alternatives

Polyrepo

Combines aspects of mono-repo and multi-repo by grouping related services into shared repositories rather than one or many single repos.

Use when: Choose when you want a balance between independent deployments and code sharing within related service groups.

Monolith

All functionality lives in a single deployable application, not separated into microservices or repos.

Use when: Choose when your system is small or early-stage and does not require microservice separation.

Summary

Mono-repo stores all microservices in one repository, easing code sharing and atomic changes.

Multi-repo splits microservices into separate repositories, enabling independent team workflows.

Choosing between them depends on team structure, scale, and deployment needs.

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