Service Decomposition¶

A transformation method — instantiates Scalable Architecture Design

Carves a running monolith into independently deployable, independently scalable services along a planned migration, so each capability can grow and ship on its own schedule.

Service Decomposition is the act of transforming an existing monolith into separate services — not the static principle of modularity, but the surgery of extracting a live system into independently deployable, independently scalable parts while it keeps running. Its two defining concerns, which set it apart from its neighbors, are the unit of independent scaling (each service becomes a capacity unit that can be scaled and deployed on its own, so the hot capability no longer forces the whole system to grow with it) and the migration (you can't stop the business to rebuild, so the split must happen incrementally and safely). Where Modular Architecture decides where the seams should be on paper, this mechanism cuts along them in a production system and sequences the cut so nothing breaks.

Example¶

A retail bank runs its accounts, payments, statements, and fraud-checking as one giant application deployed as a single unit. It scales terribly: month-end statement generation is CPU-hungry, but because everything ships together, they must over-provision the entire application to survive statement runs, and one team's change to fraud rules blocks another team's payments release for a week.

They decompose — gradually. They identify service boundaries (accounts, payments, statements, fraud) and extract them one at a time using a strangler-fig approach: a routing façade sits in front of the monolith, and as each capability is rebuilt as a standalone service, traffic for it is quietly redirected to the new service while the rest still runs in the old system. Statements goes first. Once it's its own service, it scales independently — spun up only during month-end runs and idle the rest of the time — and the statements team deploys on its own schedule. Piece by piece the monolith hollows out, with a working, shippable system at every step. The plan for that sequence is as much the mechanism as the boundaries themselves.

How it works¶

Extract along seams, in slices. Boundaries are chosen (often following an existing modular decomposition), and services are carved out one at a time rather than in a big-bang rewrite, so the system stays live throughout.
Make each service an independent unit. Each extracted service gets its own deployment, its own data, and its own scaling profile, so it can grow and ship without dragging the rest — the capacity payoff.
Route through a façade during migration. A strangler-fig façade redirects traffic to each new service as it comes online while the un-migrated remainder still serves from the monolith, keeping every intermediate state shippable.
Sequence by value and risk. The order of extraction is deliberate — usually the capability whose independent scaling or release cadence hurts most, or the one easiest to detach cleanly, goes first.

Tuning parameters¶

Extraction order — which service to carve out first. Leading with the highest-pain capability delivers value early; leading with the cleanest-cut one de-risks the approach before tackling the tangled parts.
Slice size — how much to extract per step. Small slices ship safely and often but stretch the migration; large slices finish sooner but reintroduce big-bang risk.
Data separation depth — whether each service gets its own datastore or they still share tables during transition. Full separation unlocks true independence but is the hardest, riskiest part of the cut.
Boundary granularity — how many services to split into. Finer granularity scales precisely but multiplies operational surface; coarser keeps ops simple but limits independent scaling.
Migration duration tolerance — how long the system runs half-decomposed, trading a longer, safer transition against the cost of maintaining two worlds at once.

When it helps, and when it misleads¶

Its strength is turning a system that can only grow and ship as a whole into one whose parts grow and ship independently — the hot capability scales alone, and teams deploy without blocking each other. It fits a monolith whose different parts have genuinely different scaling and change rates.

It misleads when the seams are cut badly or the pieces stay entangled. Split along the wrong boundaries — or leave services sharing a database and calling each other constantly — and you get a "distributed monolith": all the operational cost of distribution with none of the independence, because the pieces still can't deploy or scale apart.^[1] The classic misuse is decomposing for fashion rather than for a real scaling or delivery constraint, incurring the (substantial) cost of distribution to solve a problem the monolith didn't actually have. The discipline is to decompose only where independent scaling or release genuinely pays, cut along real boundaries (typically business capabilities with their own data), and migrate incrementally so every step leaves a working system rather than a half-built rewrite.

How it implements the components¶

modular_decomposition_plan — the concrete plan for which capabilities become which services in a specific running system, taking a modular design from principle to an executable split.
capacity_unit_model — each extracted service becomes the unit of independent scaling and deployment, so growth attaches to the capability that needs it rather than the whole.
migration_pathway — the sequenced, strangler-fig route from monolith to services that keeps the system shippable at every intermediate step.

It does not define the runtime contracts and partial-failure behavior between the resulting services — that is Distributed Service Model's interface_contract, coordination_boundary, and degradation_mode_map — and it does not draw the abstract seam-and-interface design, which is Modular Architecture's.

Instantiates: Scalable Architecture Design — supplies the "split a running monolith into independently scalable services" limb.
Consumes: Modular Architecture — the extraction usually follows boundaries a modular design has already identified.
Sibling mechanisms: Modular Architecture · Distributed Service Model · Platform Core / Extension Model · Horizontal Scale-Out · Cloud Scaling Pattern · Partitioning or Sharding · Resource Pooling · Vertical Scale-Up · Franchise-like Replication · Standardized Rollout Template · Scalable Governance Cadence

Notes¶

The three "decomposition" siblings form a pipeline, not a menu: Modular Architecture decides where the seams belong, Service Decomposition cuts a live system along them and migrates to services, and Distributed Service Model governs how those services then behave on the network. Skipping the migration discipline here is the single most common way a decomposition project stalls half-done, leaving a system that is neither a clean monolith nor a clean set of services.

References¶

[1] The "distributed monolith" anti-pattern: services split apart but still sharing a database or requiring lockstep deployment, so they carry the latency and operational cost of distribution while retaining the coupling of a monolith — the failure mode a poorly-sequenced or wrongly-bounded decomposition produces. ↩