Mono-repo vs multi-repo in Microservices - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Advantages of Mono-repo in Microservices

Which of the following is a key advantage of using a mono-repo for managing microservices codebases?

A Simplifies dependency management by having all services in one repository

B Enables independent versioning of each microservice without affecting others

C Reduces the risk of merge conflicts by isolating code changes in separate repos

D Allows teams to use different version control systems for each microservice

💡 Hint

Think about how having all code in one place affects dependencies.

Mono-repos centralize all microservices code, making it easier to manage shared dependencies and perform coordinated changes.

❓ Architecture

intermediate

Impact of Multi-repo on Deployment Pipelines

How does using a multi-repo approach affect deployment pipelines for microservices?

A All microservices must be deployed together in a single pipeline

B Each microservice can have its own independent deployment pipeline

C Deployment pipelines become simpler because all code is in one place

D It forces teams to use a single deployment tool for all services

💡 Hint

Consider how separate repositories influence deployment independence.

Multi-repo allows each microservice to have its own pipeline, enabling independent deployment and faster releases.

❓ tradeoff

advanced

Tradeoff Between Code Sharing and Autonomy

Which statement best describes a tradeoff when choosing between mono-repo and multi-repo for microservices?

A Multi-repo improves code sharing and team autonomy simultaneously without drawbacks

B Mono-repo increases team autonomy but makes code sharing impossible; multi-repo centralizes code sharing

C Mono-repo improves code sharing but reduces team autonomy; multi-repo increases autonomy but complicates sharing

D Mono-repo and multi-repo both provide equal code sharing and autonomy without tradeoffs

💡 Hint

Think about how repository structure affects collaboration and independence.

Mono-repo centralizes code making sharing easier but can limit independent team workflows. Multi-repo allows teams to work independently but sharing code requires extra effort.

❓ scaling

advanced

Scaling Challenges with Mono-repo

What is a common scaling challenge when using a mono-repo for a large microservices architecture?

A Build times increase significantly as the repository grows larger

B It becomes impossible to share code between services

C Teams cannot coordinate changes across services

D Version control systems do not support mono-repos

💡 Hint

Consider how repository size affects build and test processes.

Large mono-repos can lead to longer build and test times, requiring advanced tooling to maintain efficiency.

❓ estimation

expert

Estimating Repository Management Overhead

Given a microservices system with 50 services, each updated weekly, estimate which repository strategy likely requires more overhead for managing pull requests and why.

A Multi-repo, because it centralizes all code making pull requests simpler

B Multi-repo, because managing many repositories requires more coordination

C Mono-repo, because it forces independent versioning for each service

D Mono-repo, because all changes go into one place causing more merge conflicts

💡 Hint

Think about how many teams work in the same repository versus separate ones.

Mono-repos can have higher overhead due to many teams working in the same repo, increasing merge conflicts and coordination 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