When is a microservice the wrong architecture?

Scope

Use this guide when a new product or decomposition project is considering independently deployed services. The question is whether microservices solve current constraints better than a well-structured deployable unit. It does not argue that monoliths are always simpler or that existing services should be merged automatically.

Why it happens

Architecture labels carry status and ready-made diagrams. AI coding tools can scaffold many services quickly, making file generation feel like the hard part. The real cost appears later: contracts, deployment pipelines, identity, network failure, retries, observability, data ownership, migrations, on-call boundaries, and compatibility.

Benefits are also real. Independent scale, fault containment, release cadence, regulatory boundaries, or team autonomy may justify that cost. Judgment begins by naming which benefit matters and how the organization will know it arrived.

Diagnosis

Write three quality-attribute scenarios before naming services. Each scenario includes a stimulus, environment, affected artifact, desired response, and measure. Examples include a traffic burst, a schema change, a tenant-isolation incident, or a rollback during partial dependency failure.

Then examine candidate boundaries:

• Do the capabilities change and deploy independently in practice?
• Can one team own the data and production outcome end to end?
• Is the boundary stable, or does work routinely cross it?
• Does a separate failure domain reduce user impact, or add a new dependency?
• Is independent scaling material after measuring the bottleneck?
• Can the organization operate versioned contracts and distributed incidents?

If most user changes require coordinated releases and transactions across the proposed services, the boundary is working against the change pattern.

Solution

Start with modules whose interfaces and dependency directions are enforced in code and tests. Keep domain ownership and data rules explicit even in one deployment. That preserves learning without paying the network and operational tax immediately.

For a contested boundary, run a thin experiment: measure call volume, change coupling, failure propagation, deploy frequency, and scaling profile. Record a decision with triggers for extraction, such as sustained independent scaling or a proven isolation requirement. Also record triggers for stopping the split.

When microservices are justified, fund the platform work as part of the decision: service identity, deployment, contract tests, telemetry, incident ownership, timeouts, retries, and data reconciliation.

Artifact

Complete one row per candidate boundary:

Constraint	Evidence now	Benefit of separation	New coordination cost	Test/measure	Decision trigger
Independent change			Contract/version work	Change-coupling history
Independent scale			Targeted capacity	Network/queue overhead	Load profile
Failure isolation			Smaller blast radius	New dependency modes	Failure drill
Data/regulatory boundary			Stronger control	Distributed consistency	Data-flow review
Team ownership			Autonomous decisions	Cross-team protocols	Work-item analysis
Technology constraint			Specialized runtime	Skills and operations	Prototype

End the record with the selected option, rejected alternatives, assumptions, review date, extraction conditions, and rollback path.

Common mistakes

• Counting generated repositories as evidence of architectural progress.
• Splitting nouns into services without studying transaction and change boundaries.
• Assuming a network boundary creates team autonomy.
• Ignoring data migrations, partial failure, and operational ownership.
• Making a permanent choice without review triggers or evidence that would reverse it.