# Service per Team

> One team, one service — clear ownership, no shared responsibility chaos.

- **Category**: Microservices
- **Subcategory**: Service Decomposition
- **Canonical URL**: https://designpattern.fyi/patterns/service_per_team/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Payments Team owns the Payment Service. Only they can merge to its repo, deploy it, and change its API. Order Team wants new functionality → they file a request or PR to Payments Team. No shared ownership confusion.





## Trade-offs


### Advantages

- Crystal-clear ownership — no "whose bug is this?" ambiguity

- Team autonomy — no waiting for other teams to approve changes

- Naturally enforces service boundaries

- Clear on-call responsibility per service




### Considerations & Drawbacks

- Small teams can become bottlenecks for their service

- Cross-team API negotiation takes time

- Team reorganizations require service ownership transfers

- Single team as single point of failure for a service







---
**Reference**: [Original Source](https://microservices.io/patterns/decomposition/service-per-team.html)