Service Size and Granularity

Boundary size decisions are really judgments about cohesion, coordination cost, and team capacity. Chapter 10 turns the common “how big should a service be?” question into a more useful design review: what signs show that a boundary is still coherent, and what signs show that it should be split or merged?

Read the lessons in order. The first explains why there is no universal service-size rule. The second turns cohesion, coupling, and boundary tension into practical diagnostic tools. The third focuses on split signals. The fourth explains when merging services is the more disciplined move.

If a team is arguing about whether a service is too big or too small without using any real criteria, this chapter gives the criteria.

In this section

• The Myth of the Perfect Service Size
  A practical lesson on why there is no universal microservice size rule and why service quality must be judged through ownership, cohesion, and coordination cost instead of artifact counts.
• Cohesion, Coupling, and Boundary Tension
  A practical lesson on using cohesion, coupling, and boundary tension to evaluate whether a service is shaped well internally and interacts with neighbors in a proportionate way.
• When to Split a Service
  A practical lesson on recognizing split signals such as diverging change cadence, scaling mismatch, model confusion, and ownership friction without treating service extraction as a reflex.
• When to Merge Services
  A practical lesson on recognizing when supposedly separate services are carrying more coordination cost than autonomy benefit and why merging can be a disciplined correction rather than a failure.