# Service per team pattern
<a name="service-per-team"></a>

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 you assign each microservice to a single team. However, if the team is large enough, multiple subteams could own separate microservices within the same team structure. The following table explains the advantages and disadvantages of using this pattern.


****  

| Advantages | Disadvantages | 
| --- | --- | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html)  | 

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

![\[Decomposing monoliths into microservices by teams\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/service-per-team.png)