What a service boundary is for

A service boundary is a permission to stop knowing things. That is the whole product. Everything else (the deployment isolation, the team autonomy, the retries) is packaging.

The idea is older than the word "microservice" by four decades. In 1972 David Parnas published "On the Criteria to Be Used in Decomposing Systems into Modules", and the criterion he proposed was not size, or team, or technology. It was change: a module should hide a decision that is likely to be revised. The boundary earns its keep on the day the decision behind it changes and nobody outside notices.

This is worth restating in the negative, because the negative is where budgets go to die. A boundary that does not hide a decision is pure cost. It buys you a network call where a function call was, two deploy pipelines where one was, and a distributed transaction where a database transaction was, and in exchange it hides nothing, because both sides still have to know the same things at the same time. The industry name for this is "distributed monolith," which is unkind to monoliths.

I have sat in perhaps a dozen decomposition reviews, and the same test settles most arguments faster than any diagram: name the change this boundary will absorb. Not a category of change; a specific, plausible one. "We will swap the tax engine when we enter a second country" is an answer. "Payments might need to scale independently" is sometimes an answer, if someone has the traffic graph with them. "It felt too big" is not an answer, though it is the most common one offered.

There is a second, quieter purpose that Parnas could not have anticipated at 1972 team sizes: boundaries ration attention. A group of five people can hold roughly one system's worth of invariants in their heads. Conway pointed at the org-chart half of this in 1968; the cognitive half is why "one team, one service" keeps being rediscovered by people who have never read either paper. The boundary is not for the machine. Machines are happy to run a monolith. It is for the seven people who must not need to attend each other's standups.

What follows from taking the criterion seriously is mildly unfashionable. Most systems contain fewer revisable decisions than they contain teams, which means most systems deserve fewer services than they have engineers who would enjoy owning one. The correct number of services is the number of secrets worth keeping, and that number moves slowly, because business models move slowly.

None of this argues for the monolith as an identity, a subject this journal has taken up separately. It argues for boundaries as bets. A good boundary is a bet that a particular decision will change, placed at the cost of a network hop. Like any bet, it can be sized: module first, service when the change pressure becomes observable rather than theoretical.

Fifty-four years is a long time for a criterion to survive contact with the industry that ignores it. It survives because it is not advice about technology. It is advice about the future, which is the only thing a boundary has ever protected anyone from.