Mono and Multi-repos are two strategies to manage your codebase through Git. In a Mono-repo approach, you will have all your services in a single repository instead of using a repository per service like in the Multi-repos strategy.
Challenges with Mono-repos
Version Control Slowed Down
Depending on the size of your repository, the underlying version control system may start slowing down. It will impact the team of developers directly during the simple operations of cloning, pulling, rebasing and checking out branches for example.
This is one of the downsides of using Mono-repos, there are fewer chances to suffer from this using a Multi-repos approach.
Complex CI/CD
Building, testing or deploying only some parts of a repository usually requires specific configuration which also requires maintenance over time. You may end up building, testing and deploying all the services in the repo and it can take a huge amount of time over the years. The more services inside a Mono-repo, the more complex it will be to execute the CI/CD on a specific service.
On the opposite, using a Multi-repos strategy will let you take advantage of the modern CI systems that are very easy to set up.
Complex Branching
Generally, multiple teams are working in a Mono-repo, which makes it more difficult to keep your branches up-to-date. Also, the repository will end up with tons of branches and you can end up dealing with dirty merge conflicts.
Challenges with Multi-repos
Dependency Management
With a repository per module of code which depend on each other, it makes it difficult to keep them synchronized to have them working as a whole. If there is an update in one repository that breaks something in another one, it can be difficult to find it out immediately.
It can become very complex to deal with dependency management over time.
Code Duplication
With the Multi-repo approach, code duplication can happen a lot. The chances are much higher that this will happen because it can for example be impossible or difficult to call code from another repository. Also, when using an IDE, it will be difficult to refactor code for all the applications since we only have access to our actual service repository.
End-to-End Testing
While unit and integration tests for specific services or projects are easier for Multi-repos strategy, end-to-end testing can be way more complex. It will require additional CI configuration and maintenance over time.
Who is using them
The Mono-repo approach is used by Google, Facebook, Twitter and Uber for example. On the other side, the Multi-repos strategy is used by Netflix, Amazon and Lyft.
Pros & Cons
Mono-repo
| Pros | Cons |
| Handling the relationship between the project's components. | The initial setup is complex. |
| Dealing with code duplication and refactoring. | Version control slowing down with a larger codebase. |
| Improved collaboration and understanding of the codebase. | Not suitable for projects with a strong separation of concerns. |
Multi-repos
| Pros | Cons |
| Simplicity to set up. | Complex dependency management between repositories. |
| Better separation of concerns. | Code duplication happens more often. |
| Easier CI unit testing and integration testing. | Difficult end-to-end CI testing. |
Conclusion
In this article, we discussed the most important challenges that you can find using both strategies. To determine which repository structure will work the best for you, you will have to analyze the nature of your application and the developer tools that you plan to use. The most significant challenge that you should look at is probably around the CI/CD tooling for your project structure strategy.