Problem
What’s the relationship between teams and services?
Forces
- A team should be small, e.g. 5-9 people
- A team should be autonomous and loosely coupled
- The size and complexity of the team’s codebase must not exceed the team’s cognitive capacity.
- Finer-grained service decomposition improves -ilities including maintainability, testability, deployability
- Finer-grained service decomposition adds complexity
Solution
Instead of decomposing monoliths by business capabilities or services, the service per team pattern breaks them down into microservices that are managed by individual teams.
Each team is responsible for a business capability and owns the capability's codebase. The team independently develops, tests, deploys, or scales its services, and primarily interacts with other teams to negotiate APIs.
We recommend that each individual microservice be owned by only one team. However, if the team is large enough, it’s possible that multiple subteams could own separate microservices within the same team structure.
The following illustration shows how a monolith is split into microservices that are managed, maintained, and delivered by individual teams.
Resulting context
This pattern has the following benefits:
- Enables each team to be autonomous and work with minimal coordination with other teams
- Enables the teams to be loosely coupled
- Achieves team autonomy and loose coupling with the minimum number of services
- Improves code quality due to long term code ownership
This pattern has the following drawbacks:
- Teams are not necessarily aligned with end-user features
- Implementing features that span services is more complicated and requires teams to collaborate
