The decision is not “monolith or microservices?”
The useful question is: what source of friction are you trying to remove, and does distribution actually remove it? Teams often reach for microservices when the real constraints are poor boundaries, shared ownership, slow tests or a database hot path. Distribution can preserve those problems while adding network, data consistency, observability and incident complexity.
Five criteria worth scoring
| Criterion | Question |
|---|---|
| Delivery velocity | Will this choice reduce coordination and regression scope within the next 6-12 months? |
| Operational simplicity | Can the team operate the new failure modes confidently? |
| Independent ownership | Do teams genuinely need separate release and accountability boundaries? |
| Independent scale | Do domains have materially different resource or availability profiles? |
| Reversibility | How expensive is it to change direction when assumptions prove wrong? |
The middle option is often under-evaluated
A modular monolith can create explicit module APIs, logical data ownership and internal events while retaining one deployable unit. That does not make it universally correct, but it is valuable when the team needs stronger boundaries before it needs independent operations.
When microservices become justified
- A domain has a clearly different scaling or availability profile.
- A team cannot release independently without unacceptable coordination.
- Security or regulatory isolation needs are real, not hypothetical.
- Boundaries have been proven stable enough to extract.
- Distributed tracing, service-level objectives and incident practices are mature.
Change-my-mind conditions
Write these before implementation. Re-score when a material constraint changes; a single hard isolation requirement may be sufficient. The number of triggers is not a decision rule.
A boundary problem is not yet a deployment problem
In our fictional runnable example, Billing imports Workflow storage directly. Moving those classes to separate services would change the mechanism of the dependency, not automatically give the domains independent ownership. First repair the dependency through a public contract, then collect evidence about release coordination and operational isolation.
| Constraint | Evidence to request | Decision consequence |
|---|---|---|
| Release coordination | Which changes were blocked, by whom, and why? | Separate deployment is relevant only if it removes the demonstrated blocker |
| Uneven load | Per-domain resource use and a costed scale experiment | Process isolation may be enough before introducing a service |
| Ownership | Named team, support responsibility and contract change process | An unowned service adds an operational gap |
Try to falsify the recommendation
Suppose Billing must now release on an independently verified schedule and failure isolation is required by a signed system constraint. Revisit the recommendation even if the import check passes. Conversely, a traffic forecast without measurements is a hypothesis, not an extraction mandate.
Run the negative and positive boundary controls. The example validates one source rule; it does not benchmark microservices.
Source and interpretation
How to break a monolith into microservices discusses decomposition and migration. The evidence questions and worked example here are SYSLUME's own review structure.