Where the Boundary Goes

The usual way boundaries get chosen is by nouns: Orders, Users, Payments, Notifications. That produces a diagram that reads well and says nothing about failure. The question a distributed-systems reading asks instead is: what happens to correctness when the two sides cannot talk? If the answer is "nothing important, one side degrades", the boundary is well placed. If the answer is "an invariant is violated and someone has to reconcile it by hand", the boundary is cutting through something that should not be cut.

Concretely: an order and its line items share an invariant — the total must equal the sum of the items. Put a network between them and you have chosen to enforce that invariant with a protocol, forever. An order and the email confirming it share nothing of the kind: if the notification service is down, the order is still correct and the email arrives later. The first cut is expensive, the second is nearly free, and no amount of diagram-tidiness changes that.

The productive reframing is that a boundary is where you agree to accept partial failure. You should therefore put it where partial failure is cheap, which is exactly where the two sides do not share an invariant.

It is worth noticing how many boundaries already exist in a system nobody would describe as distributed. The browser and the server. The application and the database. The application and the cache. The application and the object store, the payment provider, the identity provider, the email gateway. Each of those is a machine boundary with independent failure and ambiguous call outcomes, and each of them is a place the reasoning in this domain already applies.

This matters because it changes where the effort goes. A team debating whether to extract a service often has ten existing boundaries handled carelessly — no deadline on the payment call, no idempotency on the webhook, an ORM that lazy-loads across the database boundary in a loop. Tightening those is cheaper and higher-value than adding an eleventh.

It also gives you a source of evidence. The boundaries you already have will tell you which failure modes your system actually experiences and whether your team can operate them. If the existing database boundary produces regular incidents nobody can diagnose, adding service boundaries will not go well.

A boundary placed across a tight interaction produces a chatty interface, and no amount of client-side cleverness fixes it. If rendering one page requires forty facts that live on the other side, you will either make forty calls, make one call that returns everything (and couples the two sides’ schemas), or cache aggressively (and inherit staleness). All three are worse than not having cut there.

The tell during design is a proposed interface with many small operations, or one where the caller needs to loop. The tell in production is a request count on the dependency proportional to result-set size, and a p99 that grows with page size. API Design owns the granularity discussion at the contract level; the distributed-systems point is that a chatty boundary multiplies not only latency but *failure probability* — forty calls at 99.9% each is a 96% chance the page renders completely.

The corollary is a useful design heuristic: the boundary should be where the data naturally aggregates. If one side can answer a question completely, the interface is one call. If it can only answer fragments, the aggregation belongs on its side of the line, or the line is in the wrong place.

The version of a boundary that survives contact with a growing system is data ownership: exactly one component writes each piece of state, and everyone else reads a copy or asks. This is stronger and more useful than "each service has its own database", because it is checkable and because it is what actually prevents the failure modes — two writers producing conflicts, a schema change that breaks an unknown consumer, an invariant enforced in two places and drifting.

Once ownership is fixed, most of the other questions answer themselves. Who resolves a conflict? The owner. What does a reader do with a stale value? Ask the owner, or make the write conditional. Who can change the schema? The owner, subject to a contract with the readers. What happens during a partition? Readers degrade; the owner keeps working.

The failure to establish ownership is the root of most of the pain in The Shared Database: An Honest Trade, Not a Prohibition and The Distributed Monolith: All of the Cost, None of the Autonomy, and the reason "each service owns its data" is repeated so often. Stated as a boundary rule it is sharper: a boundary is only real if no invariant and no write path crosses it.