Start with explicit domain modules and extract services only when independent scaling, deployment or ownership creates real value. Distribution adds failure modes and coordination cost.
Distribution is a cost, not a maturity badge
Microservices allow independent deployment, scaling and ownership, but they also introduce network failure, eventual consistency, distributed tracing and cross-service coordination. A modular monolith keeps deployment and transactions simpler while using explicit domain boundaries inside one application.
The question is not which architecture is modern. It is which constraints require distribution today.
Start with domain boundaries
Organise code around business capabilities rather than technical layers. Give each module a clear public interface and keep its data private from other modules. Enforce those rules with build checks and tests; a folder structure alone does not create modularity.
This work is valuable in either architecture. Poor boundaries become more expensive, not less, when moved across a network.
Extract for a measurable reason
A module may become a service when it needs independent scaling, a different reliability profile, a separate release cadence or durable ownership by another team. Record the expected benefit and the new operational responsibilities before extracting it.
Move one boundary at a time. Establish contracts, observability, idempotency and failure behaviour before redirecting traffic. Avoid a broad rewrite that changes boundaries and infrastructure simultaneously.
Match architecture to team topology
Independent services require teams capable of owning build, runtime, incidents and data evolution. If every production change still needs one central group, service boundaries have not created autonomy.
A well-structured monolith can serve a product for years and preserve the option to extract. Optionality comes from clear boundaries and disciplined ownership, not from the number of deployables.
Frequently asked questions
Is a modular monolith suitable for a startup?
Often yes. It supports fast change with lower operational overhead while preserving domain boundaries that can later become services if needed.
When should a module become a microservice?
When independent scale, deployment, reliability or team ownership produces enough value to justify network, data and operational complexity.
Further reading
Explore official documentation for the tools and architecture patterns discussed in this guide.