Name the Independent Thing

Both diagrams say microservices.

The first has four HTTP endpoints and four repositories. They share one database, move on one release train, page one on-call rotation, and require a coordinated deployment when the shared schema changes.

The second can release Payments without Ordering, lose the Payments process without losing unrelated Ordering work, rotate payment credentials inside one data zone, and send repair to a staffed Payments owner.

The label is identical. The operating contract is not.

Before debating microservices, macroservices, or SOA, name the thing expected to be independent. Is it a release, write model, process failure, scaling unit, repair path, team lifecycle, or compliance zone? Then draw the evidence which makes it independent.

Count operating boundaries, not boxes

The SVC-03 fixture carries the same four synthetic capabilities through five topologies: Ordering, Pricing, Fulfilment, and Payments. Each topology faces the same eight release, failure, scaling, compliance, repair, change, and staffing probes.

The labels are stored separately from the operational facts. Renaming every topology to renamed changes no derived graph or disposition.

Those counts are an inventory, not a score. Four processes may isolate a crash while one release train keeps changes coordinated. Three services may be enough when only Payments and Fulfilment need separate operation. One process may still contain four well-defended semantic modules.

The shared-release topology is the useful control. Its endpoints and repositories look distributed. Its releases, writes, alerts, and credential scope remain joint. Counting boxes would award independence which the operating facts deny.

A release is independent for a particular change

A backward-compatible Payments implementation change affects different units in each topology:

strong modules             commerce application
shared-release endpoints   service release train
coarse services            Buy service (Ordering + Payments)
capability services        Payments service
selective extraction       Payments service

The last two can deploy that change without moving Ordering. That is concrete release independence.

Now break the Ordering-to-Payments contract. The capability and selective topologies must expand Payments, migrate Ordering, and retire the old contract after consumer evidence exists. Two release units participate in one compatibility window.

Separate deployment machinery remains useful, but this particular change is coordinated. “Independently deployable” cannot mean that every possible change touches one artifact. It should mean that compatible changes routinely move on one unit and that cross-unit changes have an explicit migration contract.

Microsoft’s boundary guidance rejects interdependencies which force services to deploy together and recommends coarser boundaries when the right cut is uncertain. Dehghani’s decomposition guide makes the same operational point: service size matters less than the organization’s ability to build, test, release, monitor, and operate each lifecycle.

Repository count never appears in that proof.

Failure and scaling follow different graphs

Fail the Payments process in all five topologies.

The strong-module process takes all four capabilities with it. The coarse Buy process takes Ordering and Payments. The capability and selective topologies lose Payments while unrelated Ordering, Pricing, and Fulfilment processes remain available. The shared-release endpoints also contain the process fault despite their coupled release and data contracts.

That last result is important. A topology can have genuine failure isolation and poor release independence at the same time. Autonomy is not one boolean.

Fulfilment saturation produces another graph. Strong modules scale the whole application. Coarse, capability, and selective topologies can scale a Fulfilment unit. Shared-release endpoints can scale its process too, although the shared database may become the next capacity boundary.

Fowler’s Microservice Trade-Offs places independent deployment and strong module boundaries beside the costs of remote calls, consistency, and operations. It does not turn those properties into one maturity ladder. A network can isolate one resource and introduce three synchronous dependency edges in the same design.

Ask which work survives a failure and which resource actually scales. “The service is isolated” is incomplete until both answers are visible.

Data ownership has a physical consequence

Rotate credentials for the synthetic payment-data zone.

In strong modules and shared-release endpoints, the protected store also holds Ordering, Pricing, and Fulfilment data. The payment control covers all four capabilities. Coarse services reduce the zone to Ordering and Payments because both live in Buy. Capability services and selective extraction narrow it to Payments alone.

That does not prove that a separate Payments store is required. It shows what the requirement would cost in each topology.

Microsoft’s data-sovereignty guidance connects independent deployment to ownership of logic and data under one lifecycle. A service which shares a writable schema may still provide a useful interface. It has not gained an independent data lifecycle merely by moving the interface into another container.

Compliance works the same way. A box labelled Payments does not narrow key access, backups, audit evidence, incident scope, or deletion policy. The credential boundary must meet the store and operator boundary in the deployed system.

An alert route can reconnect separated boxes

The fixture diagnoses one captured payment without an accepted order. In the shared-release topology, one service-on-call owner receives and repairs both sides. In capability services, Ordering and Payments owners share the signal and the decision to reconcile or compensate.

Neither arrangement is automatically wrong. The first admits joint operation. The second needs a cross-owner protocol with enough evidence to decide who acts and when.

Staffing exposes another limit. The synthetic organization can carry three operational lifecycles. Four capability services leave one lifecycle uncovered. Putting the fourth service under a nominal team name does not add alert capacity, system knowledge, or repair time.

This is where diagrams often become optimistic. They show target ownership as current fact. A useful map records the owner who can receive the page today, the dashboard they can read, and the repair they are authorized to run. An unowned service is not autonomous. It is unattended.

The same topology changes meaning with the constraint

The reproduction applies three contexts to unchanged topology facts. It does not calculate a winner.

Capability services meet the independence requirements in the latter two contexts but exceed the declared capacity of three lifecycles. Shared-release endpoints isolate Fulfilment’s process and scaling, but their release train keeps the warehouse change coupled. Coarse services satisfy warehouse peak without separating Payments. They fail the narrower payment zone.

The disposition changes because the required independence changes. The facts do not move to flatter a preferred topology.

Selective extraction deserves more attention than it usually receives. A system can keep Ordering and Pricing together while extracting Payments and Fulfilment. It does not have to choose between one process and one process per capability. The awkward mixed diagram may describe the operating constraints more honestly than a pure style.

SOA does not settle service size

The OASIS SOA Reference Model defines service orientation as a paradigm for organizing distributed capabilities which may cross ownership domains. It deliberately separates that abstract model from concrete technology and calls granularity and coarseness relative, subjective trade-offs without a useful unqualified metric.

That is broader than a service-count argument. SOA can describe capabilities, visibility, interaction, policies, and effects without deciding whether a particular implementation should have three deployables or thirty.

Macroservice is even less formal here. It is a useful relative description for a service which deliberately groups several capabilities. It is not a standard size class. Microservice does not rescue the measurement: Dehghani explicitly argues that size matters less than independent lifecycle and operational maturity.

Use the terms to orient a conversation. Do not let them substitute for the release, process, data, call, owner, and policy graph.

Name the independence before choosing the topology

The synthetic reproduction retains five topologies, eight probes, 40 outcomes, three contexts, 35 passing tests, five primary-source responses, and 18 isolated counterfactuals. The counterfactuals select from a label or service count, infer release from endpoints or repositories, hide shared data or calls, overstate failure, scaling, staffing, and compliance, erase repair and compatibility, tune context facts, present target ownership as current, or manufacture a winner and score. All eighteen fail.

The clean export reproduces from commit 3171d6ee843850dc33de2701ec3ba34e45f7f2fe. It proves the derived consequences of the declared synthetic graph. It does not measure Brian’s production reliability, latency, compliance, staffing, cost, or service estate.

Start the next architecture discussion without a style name. Write one sentence for each demanded property:

Payments must release independently because …
Fulfilment must fail independently because …
Payment data needs an independent lifecycle because …
This team can operate another lifecycle because …

Attach an observation and owner to every answer. Only then choose the coarsest topology which supplies those properties. The label can wait.