In this analysis
The architecture can grow faster than the product
A young software team separates a new service into many deployable components before its workflows have stabilized. Every feature now requires coordinating several repositories, local environments, and release schedules. The components are individually small, but changing the product has become difficult. This hypothetical outcome is not evidence that microservices are inherently wrong. It shows that the number of services is a poor proxy for modularity.
Parnas’s foundational paper examines how the criteria used to divide a system affect flexibility and comprehensibility, using information hiding as a central design idea. 1 The enduring question is what a boundary protects from change. A network boundary that merely separates steps in a tightly coupled workflow may add operational distance without creating genuine independence.
Modularity begins inside the codebase
Fowler’s Monolith First argues that starting with a monolith can help teams discover useful boundaries before distributing them. It is practitioner guidance informed by experience, not a controlled trial proving a universal sequence. 2 Its relevance depends on the uncertainty of the domain and the team’s operating conditions.
For a hypothetical research platform, ingestion, document permissions, evaluation, and billing may initially live in one deployable application. They can still have explicit interfaces, separate ownership, and tests that prevent inappropriate dependencies. The design should make it possible to change an internal implementation without forcing every consumer to change. This is a property of the interfaces and dependency structure, not of how many servers appear in the infrastructure diagram.
A business boundary is not always a database table
The bounded-context concept describes a boundary within which a domain model has a consistent meaning. Microsoft’s domain-analysis guidance applies business capabilities and domain understanding to service modeling. 57 Both caution, in different ways, against treating the organization’s data tables as an automatic map of its services.
“Customer” may mean a billing account in one workflow and an individual user in another. Forcing both into a shared universal object can create coupling, while separating them without clear translation can create inconsistency. Our recommendation is to map the decisions and invariants that must change together. A boundary should make responsibility clearer, including which system is authoritative for a particular fact.
Distribution introduces new failure states
Lewis and Fowler describe microservices as independently deployable services organized around business capabilities, along with the trade-offs of distributed systems. AWS’s guidance on timeouts, retries, backoff, and jitter explains why remote calls require explicit failure handling. 38 A function call that once completed or threw an exception can become a request whose outcome is temporarily unknown.
Suppose a billing operation times out after the downstream service has already committed it. Retrying without a defined idempotency policy can duplicate the effect. This is not a reason to avoid every network boundary. It is a reason to include ambiguous outcomes, retry behavior, and consistency requirements in the design before celebrating independent deployment.
Independence requires an operating capability
Fowler’s microservice prerequisites include rapid provisioning, monitoring, and deployment capability. OpenTelemetry’s observability primer describes how telemetry supports understanding system behavior. 410 The combination matters because distributing a system changes the information an operator needs when something fails.
A small team may be able to operate several services well if it has strong automation and clear ownership. A larger team may struggle if deployment and diagnosis remain manual. Count the recurring work: credentials, dependency updates, on-call coverage, tracing, test environments, and compatibility management. The relevant cost is not only cloud expenditure. It includes the time spent reconstructing a user request across components during an incident.
Some state should not be casually separated
Google’s SRE discussion of distributed consensus explains the difficulty of coordinating critical state reliably across systems. 9 The appropriate consistency model depends on the application, but it should be a conscious choice. Splitting a workflow does not make its shared invariants disappear.
For the research platform, a document’s access rule and the operation that exposes its content may need a stronger relationship than an eventually updated reporting counter. Identify which failures can be repaired asynchronously and which would violate a permission or financial constraint. A modular monolith can simplify some of these relationships through local transactions. A distributed design may still be justified, but it should explain how the invariant survives the split.
Extract a service to solve an observed problem
Fowler’s Strangler Fig approach describes gradually replacing parts of a system rather than attempting a single wholesale rewrite. 6 The same evolutionary principle can guide service extraction: choose a boundary with a clear reason to become independent and preserve a controlled migration path.
Possible reasons include a substantially different scaling pattern, a distinct security boundary, or a team that genuinely needs an independent release cadence. These are proposed decision criteria, not promises of an automatic benefit. Measure the current constraint and the result after extraction. If the change adds deployment freedom but also creates a fragile chain of synchronous calls, the trade-off should be visible.
The critical boundary may be a transaction
Imagine reserving a limited resource and recording the corresponding entitlement. Inside one database transaction, the application can enforce an invariant that these changes succeed or fail together. Across independent services, the design needs a strategy for partial completion, coordination, or compensating actions. A compensation may restore a business state without erasing every external consequence.
This is an editorial example of the state-coordination concerns discussed in distributed-systems reliability literature. 9 Before splitting the workflow, write down which intermediate states are acceptable and who repairs those that are not. “Eventually consistent” is a description of a convergence property, not an explanation of what the user should see while systems disagree. If the team cannot describe those states and their recovery, the proposed service boundary is not yet a complete design.
Keep the option to change
The architectural objective is not to remain small forever. It is to preserve the ability to respond as the product, team, and evidence develop. A well-structured single deployment can be easier to split than a distributed system whose services share internal schemas and release in lockstep.
Our conclusion is to design boundaries before distributing them and to distribute them when there is a concrete operational reason. The literature and practitioner guidance support attention to information hiding, domain meaning, observability, and failure handling. None turns a particular topology into a universal answer. An architecture earns its complexity when that complexity removes a demonstrated constraint and the team can sustain the new responsibilities it creates.
Separate responsibilities early; separate deployments when there is a clear reason.
Sources & methodology
This editorial synthesizes primary research, technical standards, and original engineering documentation. It is not an original experimental study or a systematic literature review. Research findings apply to the conditions studied; product recommendations are our interpretation. Figures explain concepts and do not present experimental measurements.
Sources checked on 31 October 2026. Publication dates and preprint versions may differ; the linked record identifies the referenced work. To suggest a correction, email contact@data-sorcerers.com.
- Parnas (1972) — On the Criteria To Be Used in Decomposing Systems into Modules ↗Back to text ↑
- Fowler (2015) — Monolith First ↗Back to text ↑
- Lewis and Fowler (2014) — Microservices ↗Back to text ↑
- Fowler (2014) — Microservice Prerequisites ↗Back to text ↑
- Fowler (2014) — Bounded Context ↗Back to text ↑
- Fowler — Strangler Fig Application ↗Back to text ↑
- Microsoft — Use Domain Analysis to Model Microservices ↗Back to text ↑
- AWS Builders’ Library — Timeouts, Retries, and Backoff with Jitter ↗Back to text ↑
- Google SRE — Managing Critical State: Distributed Consensus for Reliability ↗Back to text ↑
- OpenTelemetry — Observability Primer ↗Back to text ↑
