Design
How big should a service be?
Size is the wrong ruler. Services are sized by the decisions they hide and the team that must hold them, not by lines of code.
By TIS Partners · · 2 min
The question presumes a ruler, and the ruler most teams reach for (lines of code, endpoint count, the word "micro") measures nothing that matters. The useful rulers are two: what decision does the boundary hide, and can one team hold the whole thing in their heads. Everything else is fashion.
What does the decision-ruler say?
A service boundary earns its network hop by hiding something likely to change: a vendor, an algorithm, a storage layout, a regulatory regime. Parnas wrote the criterion down in 1972 for modules, and distribution changed the price of getting it wrong, not the rule. By this ruler a service can be enormous (an entire pricing engine whose internals churn quarterly behind one stable interface) or tiny (a tax-rate lookup hiding a vendor you expect to replace). Both are correctly sized. The distributed monolith, services that must all change together, is what mis-sizing looks like: boundaries that hide nothing, hops that cost anyway.
What does the team-ruler say?
A service should fit inside one team's cognitive budget alongside everything else that team runs. The practical ceiling is not technical: it is the on-call rotation's ability to reason about the thing at 3 a.m. When a team owns eleven services, each individually "simple," the system-of-services becomes the thing nobody holds, and the incident history starts saying so in the language of cross-service mysteries. One team, few services, each earning its keep: the arithmetic is unglamorous and has not been improved upon.
What would have to be true for "smaller" to win?
Independent deployability someone actually uses (a cadence difference, a risk difference), scaling economics that diverge enough to price differently, or a fault domain worth isolating at the cost of a distributed transaction. Note that all three are observable facts, not aesthetics; when they are absent, the split delivers the costs without the goods.
And the reverse question deserves equal air: what would have to be true for merging two services to win? Teams almost never ask it, though the conditions are symmetrical: boundaries that always change together, a hop that shows up in every latency budget, an interface wider than the code behind it. Merging is not an admission of failure. It is the same sizing discipline, run in the direction nobody gets promoted for.
Our closing test, usable in any design review: ask the author to state the service's hidden decision in one sentence, and the team that owns it by name. Two crisp answers, and size will take care of itself. Two shrugs, and no ruler in the world will save the diagram.