Service Boundary Decomposition

A team draws its first microservice diagram and produces: validation-service, notification-service, integration-service, data-service, gateway-service. Six months later, placing an order requires synchronous hops through validation, then data, then integration — every business operation pays a tax to reach a layer that used to be a method call. The split looked technical because the code was organized technically; the network had merely inherited the layer chart.

Decomposing by business capability keeps each service aligned with a product outcome. A business capability is something the company does that a product manager can name, budget, and measure: take payments, price a cart, allocate inventory, dispatch a shipment, calculate tax. Each one has its own data, its own rules, its own change cadence — and, crucially, an owner who answers "did this work?" with a metric (payment authorization rate, not "validation uptime").

The contrast, side by side:

The failure is subtle because each technical service is individually reasonable. Validation is a concern! But it is not a reason to change: when a discount rule changes, the commit belongs to pricing and no one else; when a tax rule changes, tax law changed. Grouping by concern puts code that changes for different reasons into one deployable, which is the anemic-layer problem of Layered Architecture reappearing with a network hop in front of it — technical splits recreate layer coupling across the network, where every previously local call is now a latency budget, a timeout policy, and a joint deploy risk.

A practical way to find the real capabilities: list the use cases on your system's critical path as verb-noun pairs (place order, authorize payment, reserve stock, ship parcel, issue refund), then group each use case by which rules and data it must read and write in one transaction. The groups are your candidate services. authorize payment touches payment methods, risk scores, and the ledger; it never needs the shipping label printer. The verb-noun framing has a second benefit: it keeps you from creating a service with no use case — if you cannot name three use cases the service serves, it is not a service yet, it is a library waiting to happen.

Interviewers ask "how would you decompose this system?" constantly. The answer that scores: start from business capabilities and their metrics, reject technical splits explicitly with the reason above, and tie each candidate boundary to the subdomain classification from the next chapter — the shape of the cut matters as much as the fact of cutting.

The surest predictor of a bad service cut is not the org chart — it is the data. Two tables updated in the same transaction, by the same use case, for the same invariant, are one thing wearing two names. Split them across services and every query that joined them becomes a choreography: fetch here, correlate there, reconcile forever.

Boundaries drawn around data that never changes together rarely need cross-service joins. Run the analysis before drawing anything:

1. Transaction co-occurrence. Which tables are written in the same DB transaction? orders + order_lines commit together because the total must equal the sum — one service. orders and shipments are written by different flows minutes apart — a clean split.
2. Read patterns. Which queries join across the candidate line? The order-history page joining orders JOIN payments JOIN shipments is a warning: either those live in one service, or the page needs a read model built by events from each owner (see the CQRS topic later in the roadmap).
3. Change coupling. Does a schema migration to table A regularly require a migration to table B? If yes, one team owns both invariants and will ship them in lockstep regardless of your diagram.

When a legitimate boundary still needs a join, there are exactly three honest answers, in preference order:

1. Redesign        — move the field, or accept duplication of a stable fact
                     (customer's display name copied at order time: fine,
                      customer's balance copied: never)
2. Query at source — the owning service exposes the query (GET /shipments?order=...);
                     the caller correlates. Simple, but adds a runtime dependency.
3. Local projection — subscriber maintains its own denormalized read copy from events.
                     No runtime dependency; pays in eventual consistency.

What you must not do — and what production systems do under schedule pressure — is reach into the other service's database "just for a read." It recreates a shared schema across the network with none of a shared schema's speed: no transactions, no referential integrity, no owner, and a silent coupling that surfaces as an outage when the other team adds a column.

The subdomain classification sharpens granularity decisions. Domain-driven design sorts subdomains into core (the differentiator — for a delivery company, route optimization), supporting (needed but not differentiating — warehouse management), and generic (commodity — email delivery, address validation). Core subdomains deserve fine-grained, independently evolving services because their change rate is high and their team is invested. Generic subdomains deserve the opposite: buy it, wrap it conformist, give it as little of your model as possible. Spending architectural brilliance on a commodity subsystem while the core lives in a shared monolith is inverted investment — a failure mode that shows up in roadmaps far more often than bad diagrams.

Granularity traps round out the checklist. Nanoservices: one service per entity or per class, so a use case fans out to nine hops; rule of thumb — a service should own at least a complete aggregate and a deploy pipeline worth of value. Premature duplication: splitting one capability into orders-v1 and orders-v2 "for safety" while both co-change. Org-shaped cuts: services mirroring job titles rather than capabilities. Validate each candidate cut with three questions: does one team own it? does it own data that changes together? can its failure be tolerated alone? A cut that fails two of three is a module, not a service — and Modular Monolith already told you what to do with modules.

Boundary decisions fail when they happen in a whiteboard afternoon by two architects and get announced as fact. The alternative is a short, evidence-producing workshop whose artifacts — not opinions — carry the decision into review. Here is a sequence that fits two days.

Day 1 morning: map the flow, not the services. With product and engineering in one room, lay out domain events in temporal order on a wall (or a Miro board): OrderPlaced, PaymentAuthorized, StockReserved, LabelPurchased, OrderShipped. Every event gets an actor and the data it carries. The event names come from the business language — this is where Bounded Contexts and the capability list meet, because the noun that appears consistently in an event's payload is the language of one context.

Day 1 afternoon: draw candidate boundaries and test them. Group events into clusters, then run each cluster through three tests:

invariant test   — can all rules for this cluster be stated without asking who asks?
data test        — do these tables get written in one transaction / one use case?
change test      — does git history show these files co-changing? (same command as
                   the cohesion chapter, run on the monolith before it splits)

Clusters passing all three are candidate services. Clusters failing the data test usually mean you split an aggregate; failing the change test means two services will co-change into a distributed monolith — merge them or move the seam.

Day 2: assign the non-functional profile. For each candidate, write down scale factor, latency budget, availability need, and failure tolerance ("if pricing is down, can checkout proceed with last-known prices?"). This step converts a structural argument into an operational one: two candidates with identical profiles are often better merged; wildly different profiles (the 10× CPU document generator from the extraction triggers) are strong evidence for a cut. Then classify each subdomain core/supporting/generic and attach an owner team — an unowned service in the diagram becomes an unowned service in production, which is the single most reliable predictor of an outage nobody can explain.

The artifacts that survive the meeting: a one-page map (clusters, arrows, event names, owner teams), the three test results per boundary (so the reasoning is auditable), and an explicit open questions list ("shipping/fulfillment seam disputed — validate with co-change data next sprint"). Disputed seams get data, not votes.

Common workshop failure modes: letting the existing package structure anchor the clusters (start from events instead — packages encode history, not truth); drawing ten services for a system with four capabilities (map only the critical path first); skipping the failure-tolerance column, which is where cross-service dependencies get exposed as "everything needs everything"; and letting the loudest team claim the shared names (every team wants customer-service — the word is a homonym, send it back through the context exercise).

For interviews, compress this into a repeatable narrative: events → clusters → three tests → non-functional profile → owners. Then do what most candidates cannot: name what would change your mind. "If the change test showed orders and payments co-changing weekly, I would keep them in one service until the history disagreed." A decomposer who can be wrong with specific data is exactly who teams want making cuts that are expensive to reverse — and your final sentence in the interview should be that seam decisions are cheap while they are modular and dear once they are network calls, which sets up the next topic: how those services will actually talk.