Service per team pattern

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 code base. 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 is 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 table provides the advantages and disadvantages of using this pattern.

Advantages	Disadvantages
Teams act independently with minimal coordination. Code bases and microservices are not shared by multiple teams. Teams can quickly innovate and iterate product features. Different teams can use different technologies, frameworks, or programming languages. Important: These should be hidden behind a well-defined and stable public API.	It can be difficult to align teams to end-user functionality or business capabilities. Additional effort is required to deliver larger, coordinated application increments, especially if there are circular dependencies between teams.

The following illustration shows how a monolith is split into microservices that are managed, maintained, and delivered by individual teams.