Service Decomposition and Boundary Design

The core idea: Service decomposition is a cohesion trade-off: a boundary is strong when behavior, language, authority, and change pressure belong together strongly enough to justify distributed coordination.

Core Insight

Suppose the learning platform team is deciding whether to split identity, catalog, enrollment, billing, notifications, and live classes into services. Those names sound plausible, but names are not boundaries. The real question is whether each candidate groups behavior that can be owned, changed, secured, and operated as a coherent capability.

Enrollment is a useful example. It is not merely an enrollments table or a set of CRUD endpoints. It includes eligibility rules, seat allocation, waitlists, cancellation policy, enrollment history, and sometimes payment or certificate prerequisites. Those behaviors use the same domain language and change under the same product pressure: what does it mean for a learner to take a place in a course?

The misconception to correct is that decomposition is mainly a size problem. A tiny service can still be weak if it has no real authority. A larger service can be healthy if it owns one coherent policy area and lets other services depend on it through clear contracts. The goal is not more pieces. The goal is boundaries that reduce coordination rather than multiply it.

This lesson is different from the migration lesson before it. Migration asks how to extract a plausible boundary safely. Decomposition asks how to decide whether the boundary is plausible at all. The design work is to test cohesion, authority, and workflow friction before turning a diagram into network calls.

Capability Cohesion

A strong service boundary clusters behavior that changes for the same reason. If eligibility, seat allocation, waitlists, cancellation, and enrollment history are always discussed by the same product owners, use the same vocabulary, and change together, they probably belong inside one enrollment capability.

cohesive capability:
  enrollment
    -> eligibility rules
    -> seat allocation
    -> waitlists
    -> cancellation policy
    -> enrollment history

fragmented capability:
  eligibility service
  seat service
  waitlist service
  cancellation service
  each needs the others for ordinary decisions

The fragmented version may look cleaner on a diagram, but it can make every ordinary enrollment decision a distributed workflow. A boundary that forces constant collaboration between services is usually too thin. It has separated code that still behaves like one policy area.

The trade-off is granularity versus cohesion. Smaller services can create focused ownership, but only when the split follows a real change pressure. If the split separates rules that always move together, the system pays coordination cost without gaining autonomy.

Authority and Data Ownership

A boundary becomes weak very quickly when one service owns the rules but several other services can mutate the state those rules depend on. If enrollment owns seat allocation, then enrollment should usually be authoritative for seat state and enrollment records. Other services may read through APIs, events, or replicated views, but they should not all write critical enrollment state directly.

strong boundary:
  enrollment service
    owns enrollment rules
    owns enrollment records
    owns seat allocation state
    publishes facts to others

weak boundary:
  enrollment owns rules
  catalog, billing, and gateway also write enrollment rows

The issue is not that services may never share data. The issue is authority. Who is allowed to decide? Who can change the state that decision depends on? Who must explain an incident when the invariant breaks? If those answers point to different teams, the boundary is mostly cosmetic.

This also shapes integration. A service can expose read APIs, publish events, or feed read models without giving up ownership of critical writes. Reads can be flexible. Authority should be explicit.

The trade-off is short-term integration convenience versus long-term correctness. Shared writes can unblock a release, but they make later consistency, ownership, and incident response much harder to reason about.

Workflow Pressure Test

Static diagrams are too forgiving. The best way to test a decomposition is to walk through real workflows and count the coordination it creates. Consider a learner buying a course:

learner buys course
  -> identity confirms account
  -> catalog confirms course is sellable
  -> billing authorizes payment
  -> enrollment grants seat
  -> notifications send receipt

Some cross-service interaction is normal because capabilities differ. But if enrollment has to synchronously ask five tiny services before it can decide anything, the design may have fractured one capability into fragments. If several teams argue about who owns the seat count, the boundary is not clear. If support cannot explain a failed purchase because every service holds one tiny piece of the truth, the decomposition is too expensive.

Useful warning signs include:

• one basic business action requires a long chain of synchronous calls
• several services claim partial ownership of the same concept
• multiple services need direct writes to the same core state
• callers know too much about another service's internal workflow
• incidents require many teams because no boundary owns the outcome

The trade-off is independence versus interaction debt. More boundaries promise more independent change, but every boundary is also a contract, failure point, and operational responsibility.

Operational Failure Modes

Issue: Splitting by table, endpoint, or technical layer.

Clarification / Fix: Start from workflows, language, and policy ownership. Data design should reinforce a capability boundary, not define it by itself.

Issue: Mistaking small services for strong services.

Clarification / Fix: Optimize for cohesive authority and independent evolution. A tiny service that must call its neighbors for every decision is usually not autonomous.

Issue: Letting several services share write authority over core state.

Clarification / Fix: Be flexible about reads and projections, but strict about the source of truth. If one service owns the policy, it should usually own the critical writes.

Issue: Reviewing only the static architecture diagram.

Clarification / Fix: Walk real user and operational workflows. A boundary is convincing only if ordinary behavior can cross it without excessive coordination or ambiguous ownership.

Connections

The first lesson in this track explained why a microservice boundary must earn its distributed cost. This lesson gives the design tests for where that boundary should go: cohesion, authority, and workflow pressure.

The migration lesson before this one assumed billing was already plausible and focused on how to extract it safely. This lesson moves one step earlier and asks whether billing, enrollment, catalog, or another capability is coherent enough to deserve service ownership.

The next lesson builds on this one by asking how strong boundaries communicate. Once capabilities are separated, request-response, commands, and events become choices about timing, coupling, and failure semantics.

Resources

• [BOOK] Domain-Driven Design
  • Focus: Review bounded contexts as a foundation for boundary design.
• [BOOK] Monolith to Microservices
  • Focus: Connect extraction strategy to ownership and data boundaries.
• [ARTICLE] Microservice Premium
  • Focus: See why weak boundaries make distributed systems more expensive than teams expect.
• [ARTICLE] Bounded Context
  • Focus: Use bounded context as a lens for language, model, and ownership boundaries.

Key Takeaways

• Strong service boundaries follow cohesive capability, not table shape, endpoint count, or service size.
• Authority matters: the team that owns a policy usually needs authority over the state that enforces it.
• Workflow pressure reveals bad decomposition faster than static diagrams; excessive coordination is a design signal.