All playbooks
Playbook · Design and build · 7 steps
Deciding whether to split into services
Microservices solve organisational problems at a technical price. Make sure you have the problem first.
“My First Law of Distributed Object Design: Don't distribute your objects”
- 1Microservice PremiumIs our complexity high enough to pay the fixed overhead of services?Microservices carry a fixed overhead that only pays off above a certain level of complexity.Open
- 2Monolith FirstCould a well-structured modular monolith give us most of the benefit for now?Start with a well-structured monolith; split into services only once the boundaries and the need are proven.Open
- 3Bounded ContextWhere are the real domain boundaries? Split along those, not along technical layers.A model is only valid inside an explicit boundary; the same word can mean different things in different contexts.Open
- 4Coupling and CohesionWill each service change on its own, or will most changes touch several?Keep things that change together close together, and things that change independently apart.Open
- 5Conway's LawDoes each service have one team that can own it end to end?Organisations design systems that mirror their own communication structures.Open
- 6Starbucks Does Not Use Two-Phase CommitWhich workflows span services, and how will they compensate instead of locking?Real businesses scale through asynchronous, compensating processes, not distributed transactions.Open
- 7Eventual ConsistencyWhere will data be briefly out of date, and can the business live with that window?Replicas may disagree for a while but converge when updates stop. Design the business around the window.Open