Microservices do not require one repository per service. You can build a microservices architecture in a monorepo or across multiple repositories; the repository choice changes how teams coordinate, share code, manage access, and run builds—not the architecture of the running system.
What are microservices?
Microservices are an architectural style for building an application as a suite of small, autonomous services organized around business capabilities. Services communicate through well-defined interfaces, can be deployed independently, and own their data or state where appropriate. They may use different languages, frameworks, and storage technologies. These are runtime and organizational boundaries, not rules about where source code must be stored. Microsoft’s microservices architecture guidance describes these characteristics.
That autonomy has a cost: a service call across a network is slower and less reliable than an in-process call, so distributed systems are harder to program. Martin Fowler’s discussion of microservices trade-offs highlights both independent deployment and strong module boundaries, as well as the complexity introduced by distribution.
What is the difference between a monorepo and multiple repositories?
A monorepo stores multiple projects or services in a single source repository. A multirepo, also called a polyrepo, stores projects or services in separate repositories. Neither choice determines whether services run as microservices. The distinction is how code is managed and delivered across teams. Microsoft frames the choice around team topology, tooling maturity, and the amount of code shared between services in its microservices CI/CD guidance.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
| Concern | Monorepo | Multiple repositories |
|---|---|---|
| Code sharing and standards | Sharing code and standardizing tooling are easier to coordinate in one source tree. | Sharing code and enforcing common standards require deliberate coordination across repositories. |
| Refactors and discoverability | Broad refactors and viewing the code in one place are easier. | Changes spanning repositories require coordination; code is distributed across separate source trees. |
| Ownership and permissions | One repository can make access control more complex, even when teams own distinct services. | Repository boundaries can clarify team ownership and support repository-level permissions. |
| Builds and delivery | Large codebases can require scalable tooling and more complex deployment processes; shared-code changes may affect many services. | Teams can use different build systems, CI pipelines, and branching strategies, but must coordinate changes across repositories. |
| Change coordination | One repository can make coordinated edits easier, though concurrent work may lead to merge conflicts. | Separate repositories may reduce merge conflicts, but cross-service changes and dependency updates need coordination. |
The qualitative comparison reflects the concerns described in Microsoft’s CI/CD guidance and GitHub’s guidance on repository architecture strategy and implementing polyrepo engineering.
Should each microservice have its own repository?
Not by default. A service can have a distinct owner, interface, data boundary, and deployment pipeline while sharing a repository with other services. A separate repository may make sense when teams need strict repository-level permissions, operate on independent lifecycles, or have strong organizational separation. Conversely, a small team making frequent coordinated changes or sharing substantial code may find a monorepo easier to manage—provided it can scale its build and CI tooling and preserve clear ownership boundaries.
These are decision heuristics, not universal rules. GitHub’s polyrepo engineering guidance notes that multiple repositories do not force teams to use a common build system, CI pipeline, or branching strategy, while still requiring deliberate cross-repository coordination.
How to choose a repository model
Evaluate the way your teams build and operate services rather than treating repository layout as a proxy for microservice quality. Use these questions to guide the choice:
- Team topology: Do teams own distinct services, or do they work closely in one group?
- Shared code: How often do services need common libraries or coordinated changes?
- Build and CI capacity: Can your tooling test and deliver the affected projects efficiently from a large repository?
- Access control: Do teams need permissions separated at the repository level?
- Release independence: Do services genuinely have independent delivery lifecycles, or are changes commonly released together?
- Operational maturity: Can teams manage cross-service dependencies, interfaces, and deployments without creating avoidable coupling?
If many changes span services and shared code is substantial, a monorepo can reduce coordination overhead, assuming its tooling and ownership practices can handle the scale. If permissions, organizational separation, or genuinely independent lifecycles dominate, multiple repositories may fit better, provided teams deliberately manage standards and cross-repository dependencies. Microsoft’s guidance likewise treats the decision as dependent on team topology, tooling, and code sharing rather than prescribing one layout for all microservices.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What repository layout cannot solve
A repository split does not by itself create autonomous services. If services cannot be deployed independently, lack clear business boundaries, or depend on frequent coordinated changes, putting each in its own repository will not make them independent. Likewise, keeping services together does not prevent independent deployment when boundaries and delivery processes support it. Choose the repository model to support your teams’ actual work; assess service boundaries and operational independence separately.
Quick Recap
Best Value
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
