Interactive design lab

Microservices Decomposer

What is service decomposition?

Service decomposition decides which business capabilities and data belong together, and whether any boundary has enough independent change, scale, and ownership to justify a separate deployment.

Step 1

Model

Place capabilities in a modular core or independent services, assign one data owner, then tune change autonomy, traffic isolation, team alignment, synchronous calls, peak load, and operational capacity.

Step 2

Observe

Compare candidate boundaries, dependency crossings, transaction spans, synchronous depth, ownership conflicts, migration order, and operational consequences. A modular monolith remains valid when local coordination is cheaper.

Step 3

Challenge

Start with the modular core, inject each challenge, then extract only payments and notifications. Compare the request path and operational burden before trying the distributed preset.

Boundary evidence workbench

Decompose only when the evidence earns it

Assign capability and data ownership, measure change and runtime coupling, then pressure-test the result. A modular monolith is a successful outcome when network boundaries add cost without real autonomy.

Starting architecture

Choose a hypothesis, then edit each boundary

Presets change deployment units only. Ownership and coupling evidence remain visible so the recommendation can disagree with the chosen architecture.

Loop 1 · Capability and ownership

Place one business boundary

Select a capability, decide whether it needs an independent deployment, and assign exactly one write owner.

Payments

Authorizes money movement and protects ledger invariants.

2 data sets

Deployment boundary

Accountable data owner

payment-intentsledger

Loop 2 · Change, traffic, and team coupling

Measure whether the seam is real

Strong boundaries change independently, isolate load, have one capable owner, and avoid fine-grained synchronous calls.

Independent change86%How often this capability can ship without coordinated code changes.Traffic isolation68%How independently this workload can scale and shed load.Team alignment94%How clearly one team can own delivery and incidents.Synchronous calls per request1Fine-grained calls increase runtime and release coupling.

System peak traffic18000 req/sUsed to estimate pressure on the selected capability.Operational team capacity3 teamsTeams able to own deploys, alerts, on-call, and recovery.

Evidence

75/100

Extraction confidence

Boundary load

5.9K/s

19% utilized

Cross calls

Per modeled request

Ops load

1.0

3 team capacity

Candidate boundary map

Deployment, dependency, and data ownership

1 deployment units0 cross-boundary dependencies

Web and mobile clients

One process and transaction boundary

Modular commerce core

6 modules

Independent deployables

No independent service is required yet. Module APIs preserve boundaries without distributed-system overhead.

Dependency evidence

IdentityNotifications · localCatalogInventory · localCheckoutIdentity · localCheckoutInventory · localCheckoutPayments · localCheckoutNotifications · local

Transaction span

Trace a business invariant across boundaries

Identity

Local module · Experience

Checkout

Local module · Commerce

Inventory

Local module · Commerce

Payments

Local module · Payments

Notifications

Local module · Platform

Consistency domains

One local commit

Sync call depth

Cross-boundary hops

Modeled p99

74 ms

Illustrative path latency

Availability

99.98%

Request-path estimate

Architecture challenge

Break the healthy assumptions

Each challenge changes the same request, ownership, and capacity model.

Healthy baseline

Normal traffic exposes the design cost without an injected incident.

0 dependency edges now cross a deployable boundary.
Place an order can commit inside one consistency domain.
Every data set has one accountable write owner.
Payments retains 81% modeled headroom.
The synchronous path has 0 cross-boundary hops.

Coupling evidence

Which boundaries have earned extraction?

Migration order

Move the least coupled boundary first

No service extraction is queued

First enforce module APIs, remove shared writes, and capture runtime dependency traces. Revisit extraction when one boundary needs independent change, scale, or ownership.

No quiz questions available

Could not load questions file