# Service

> A codebase with its own deploy pipeline, owned by one team. Splitting a monolith into services lets each team ship and scale on its own, at the price of a network hop between services and failures that can travel across them.

Team

## In Quorum

A Company starts on one Service, the monolith, and every Feature that no other Service names stays with it. The Service boundaries Research (Series B) splits live Features into a new Service with a name and an owning team, for 0.3 of the moved part of the codebase in Dev Hours. The owner builds that Service’s backlog and is paged when it breaks, and a bad deploy fails only the Service that shipped it. Two Services on one Database add half again to the coordination penalty, so k is multiplied by 1.5 until a Service names its own Database Node.

## Design

[Services](https://wiki.playquorum.dev/design/08-team-and-velocity.md#services)

## Read next

[Conway's law](https://wiki.playquorum.dev/glossary/conways-law.md), [Blast radius](https://wiki.playquorum.dev/glossary/blast-radius.md), [Tech debt](https://wiki.playquorum.dev/glossary/tech-debt.md), [Strangler pattern](https://wiki.playquorum.dev/glossary/strangler-pattern.md)

## Learn more

- [Martin Fowler: MonolithFirst](https://martinfowler.com/bliki/MonolithFirst.html)
- [Martin Fowler: Microservices](https://martinfowler.com/articles/microservices.html)
- [microservices.io: Monolithic architecture](https://microservices.io/patterns/monolithic.html)

## See also

- [Glossary](https://wiki.playquorum.dev/glossary.md)

Source: https://wiki.playquorum.dev/glossary/service