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.
Service size is one of the most misused ideas in microservices design. Teams often ask how many endpoints, classes, tables, or lines of code a service should have, as if there were a universal answer hiding behind a metric. There is not. A large service can still be healthy if it owns a coherent capability and one team can understand, change, and operate it confidently. A tiny service can still be unhealthy if it exists mainly as a thin pass-through that creates more coordination than autonomy.
That is why “perfect size” is the wrong target. The stronger question is whether the boundary is carrying the right amount of business responsibility, operational burden, and external coordination for the organization that owns it.
flowchart TD
A["Ask 'Is it too big or too small?'"] --> B["Check cohesion"]
A --> C["Check external coordination cost"]
A --> D["Check team ownership and operability"]
B --> E["Review boundary quality"]
C --> E
D --> E
What to notice:
Popular rules of thumb often sound persuasive:
Each rule captures part of the truth. None of them is precise enough to drive real design by itself.
For example, “one thing” can mean:
Only some of those make good architectural boundaries. If a team interprets “one thing” as “one entity,” it may create a service-per-table anti-pattern. If it interprets “one thing” as “one business capability with coherent rules,” the result may be much stronger.
Some healthy services are larger than architects first expect because they:
This is why a mature modular monolith component or a larger domain service is not automatically a mistake. If the service has clear ownership, strong cohesion, manageable operational behavior, and deliberate external contracts, its size may simply reflect the domain honestly.
Small services often create architectural confidence because they look tidy. But smallness can hide several problems:
In those cases, the service is not “well-sized.” It is under-scoped relative to the actual business or workflow boundary.
A better review asks:
These questions force the conversation away from vanity metrics and toward architectural behavior.
One way to make the conversation concrete is to evaluate a service using a short boundary record:
1service: pricing
2artifact_size:
3 endpoints: 14
4 tables: 6
5 deployables: 1
6quality_questions:
7 coherent_business_capability: true
8 one_team_can_operate_it: true
9 external_chattiness: medium
10 independent_change_value: high
11review_note: size alone is not a concern; coordination cost and capability cohesion matter more
What this demonstrates:
The right size for a service depends on:
A team with strong tooling and clear domain boundaries may own several medium-sized services comfortably. A smaller team with weaker tooling may be better served by fewer, larger boundaries for longer. This is one reason copied microservice patterns fail across organizations: the surrounding conditions are different.
Some teams unconsciously prefer smaller services because they look modern or because the architecture diagram appears more granular. Others prefer larger services because splitting feels risky. Both instincts can distort decision-making. The healthier approach is to ask which shape produces:
That turns service size into an engineering decision instead of an aesthetic one.
A team argues that a service with twelve endpoints and six tables is “too big for microservices” and should be split immediately, even though one team owns it clearly, most changes stay internal, and neighboring services interact with it through a stable contract. Is that strong reasoning?
Usually no. The stronger reasoning is that the service should be judged through cohesion, ownership, and coordination cost rather than through raw counts. If the boundary is coherent and operationally healthy, the fact that it is not tiny is not itself a reason to split it.