▶ YouTube Summaries

Splitting a capability that three teams must negotiate over does not make delivery independent — it gives the same ownership fight more places to fail. Prove the boundary inside the monolith first, and extract only when delivery and reliability evidence says the capability has earned the distributed-systems bill.

The boundary problem, misdiagnosed

If three teams need permission to change the same capability, the release is slow, the data is shared, and nobody can say who owns the customer outcome. Drawing hexagons and buying Kubernetes doesn't repair that; it attaches timeouts, retries, trace hunting, version skew, rollout order and another pager to every argument you already had.

The microservice premium

Distribution has a running bill: deployment, monitoring, failure handling, data coordination, compatible contracts. A service earns that bill only when one team owns a stable capability — its data, its contract, and how it runs in production.

Four tests for a real boundary

• Can one team change it without a committee?
• Can everyone else use a contract instead of grabbing its tables?
• Can its owner deploy it, see its traffic, and recover it when it breaks?
• Does it actually need to change or scale differently from the rest of the product?

Prove it locally before extracting

If those answers are vague, establish the boundary inside the monolith: give the module an internal API, stop direct database access, encode ownership and dependency rules in code review and CI, and track how often that team waits on unrelated releases or approvals. When the boundary holds locally and delivery or reliability pressure keeps rising, extraction has evidence behind it.

Until then, service count is inventory. A boundary is what lets work move without a committee.