Executive Summary
- The question is when—if ever—distributed complexity beats shared deploy cycles.
- Modular monoliths enforce seams in one deployable; microservices split deployables and usually data ownership.
- Team topology and change-frequency asymmetry matter more than fashion diagrams.
- Shared databases across 'services' recreate a distributed monolith with worse failure modes.
- Extraction should follow strangler patterns with contracts, observability, and rollback.
- Microservices are not an automatic scalability upgrade.
Timing decision
The question is rarely 'monolith or microservices forever.' It is when—if ever—the cost of shared deploy cycles, coupled failure domains, or conflicting team ownership exceeds the cost of distributed systems complexity.
A modular monolith keeps one deployable unit while enforcing internal boundaries (modules, packages, bounded contexts). Microservices split deployables and usually data ownership along those boundaries.
Choose based on team topology, change frequency asymmetry, scaling asymmetry, and operational maturity. Fashionable diagrams are not evidence. Microservices do not automatically equal scalability.
Seams before services
If you cannot draw and enforce module seams in one codebase, microservices will not create those seams for you—they will network your confusion.
Domains, teams, and deploy independence
Domain boundaries should reflect business capabilities with clear interfaces. If two modules always change together and share transactions, they may be one domain pretending to be two.
Team structure matters: multiple teams blocked on one release train is a signal. One small team operating twenty services is usually a liability.
Deploy independence is valuable when release cadence and failure isolation truly differ. It is expensive when every change still requires coordinated releases across services.
Growth continuum
| Feature | Signal | Modular monolith leans | Microservices lean |
|---|---|---|---|
| One team / early product | Usually sufficient | Often premature | |
| Independent release needs | Module boundaries first | Extract hot domains | |
| Scaling asymmetry | Vertical + modularization | Scale extracted services | |
| Ops maturity low | Prefer monolith | High risk |
Shared data and transactions
Shared mutable databases across services recreate the hardest coupling with distributed failure modes. Prefer module-owned tables in a monolith, then database-per-service only when extraction is real.
Transactions that span many domains become sagas or eventual consistency in microservices. That is a product and UX decision as much as a technical one.
Contracts (APIs, events) must be versioned. Local development and testing complexity rise sharply with service count—budget for it explicitly.
Observability and operational maturity
Microservices require mature logging, tracing, metrics, on-call, CI/CD, and secure service identity. Without that, failure isolation claims are theoretical.
Infrastructure cost includes orchestration, networking, and cognitive load—not only cloud line items. Provider capacity guarantees depend on configuration and operations.
Release coordination, contract testing, and rollback drills should exist before wide extraction—not after the first multi-service outage.
Extraction and strangler path
Extraction criteria should be written: independent deploy need, scaling asymmetry, team ownership, failure isolation requirement, and clear interface.
Strangler migration routes traffic gradually, keeps the monolith as fallback where needed, and avoids big-bang rewrites. Events and interfaces come before deleting monolith code.
What must remain deterministic during migration: authZ, money paths, and data ownership during dual-run. What can be automated: deploy pipelines and canaries—with human approval for cutovers.
Phased growth path
When each path is unsuitable
Microservices are unsuitable when the organization cannot operate them, when domains are unclear, when a shared database would remain, or when the product is early and learning.
An unmodular monolith is unsuitable when multiple teams thrash on one deployable and seams are already known—modularize first.
A modular monolith remains appropriate for many products indefinitely. That is a success condition, not a compromise.
Failure modes
Distributed monoliths, chatty synchronous webs, missing tracing, and partial deployments without rollback are common failure modes.
Validate before build: seam map, team ownership, transaction boundaries, and ops maturity score. Audit deploy permissions and production change control.
Implementation checklist
Do not extract services to chase a diagram.
Decomposition readiness
1Seams
- Bounded contexts drawn
- Module ownership assigned
- No circular dependencies
2Ops
- Tracing/metrics baseline
- CI/CD and rollback
- On-call capacity
3Extraction
- Written criteria
- Contract/event design
- Strangler plan
How Digital Elliptical helps
Digital Elliptical helps engineering leaders choose and execute growth paths: strengthening modular monoliths when that is enough, and extracting services when topology and failure domains justify the cost—aligned with DevOps readiness.
We do not guarantee velocity improvements from microservices or a universal target architecture. Timing depends on discovery of org structure, operational maturity, and measured delivery pain.
Main-Agent ownership (Prompt 6): Re-authored to reject microservices-as-scalability-upgrade, emphasize seams-first, and expand strangler/ops maturity requirements.