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

Practice - 5 Tasks

1fill in blank

easy

Complete the code to identify the repository type used when all microservices share a single codebase.

Microservices

if codebase == 'all services in one repository':
    repo_type = '[1]'

Drag options to blanks, or click blank then click option'

Amono-repo

Bmulti-repo

Cdistributed-repo

Dsingle-service

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing mono-repo with multi-repo.

A mono-repo stores all microservices in a single repository.

2fill in blank

medium

Complete the code to describe the repository type where each microservice has its own repository.

Microservices

if codebase == 'each service in separate repository':
    repo_type = '[1]'

Drag options to blanks, or click blank then click option'

Amono-repo

Bshared-repo

Cmulti-repo

Dsingle-repo

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up mono-repo and multi-repo.

A multi-repo means each microservice has its own repository.

3fill in blank

hard

Fix the error in the statement about repository management for microservices.

Microservices

The [1] approach uses multiple repositories, one per microservice.

Drag options to blanks, or click blank then click option'

Acentral-repo

Bmono-repo

Csingle-repo

Dmulti-repo

Attempts:

3 left

💡 Hint

Common Mistakes

Using mono-repo instead of multi-repo.

Multi-repo means multiple repositories, one for each microservice.

4fill in blank

hard

Fill both blanks to complete the advantages of mono-repo and multi-repo respectively.

Microservices

Mono-repo simplifies [1] and multi-repo improves [2].

Drag options to blanks, or click blank then click option'

Adependency management

Bindependent deployment

Ccode duplication

Dteam collaboration

Attempts:

3 left

💡 Hint

Common Mistakes

Swapping the advantages of mono-repo and multi-repo.

Mono-repo simplifies dependency management by centralizing code. Multi-repo allows independent deployment of services.

5fill in blank

hard

Fill all three blanks to complete the trade-offs between mono-repo and multi-repo.

Microservices

Mono-repo can cause [1] issues, while multi-repo may increase [2] and require more [3].

Drag options to blanks, or click blank then click option'

Ascaling

Bcomplexity

Ccoordination effort

Dsecurity

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing security with coordination effort.

Mono-repo can have scaling issues due to large codebase size. Multi-repo increases complexity and needs more coordination among teams.

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