Modular Monolith vs Microservices: Choosing an Architecture That Fits Your Team
Modular monolith vs microservices: how they differ on deployment, data, scaling, operations and team size, and when to extract services later.
Modular monolith or microservices?
Most growing products and teams are better served by a modular monolith: one deployable application with strong module boundaries, each owning its data. Move to microservices for specific parts when several teams need independent deployment, parts have very different scaling or reliability needs, and you have the operational maturity for distributed systems. Martin Fowler's MonolithFirst and microservice prerequisites articles explain the reasoning (MonolithFirst; prerequisites).
This guide is for CTOs and technical founders of SaaS and business applications. For ecommerce platforms specifically, see ecommerce microservices vs monolith.
Key takeaways
- Architecture should fit team size and operational maturity.
- Module boundaries matter more than deployment units.
- Each module owns its data; no reaching into other modules' tables.
- Extract services for a reason, not by default.
- Microservices need automation, monitoring and tracing first.
Comparison
| Factor | Modular monolith | Microservices |
|---|---|---|
| Deployment | One unit | Many independent units |
| Team fit | One to a few teams | Several autonomous teams |
| Data | One database, schemas or tables per module | Database per service; eventual consistency |
| Calls between parts | In-process, fast, transactional | Network calls; partial failures |
| Scaling | Scale the whole app; often enough | Scale services independently |
| Operations | Simpler monitoring and debugging | Distributed tracing, service discovery, more infrastructure |
| Change | Refactoring across modules is easier | Contracts between services must be versioned |
Designing good modules
- Draw boundaries around business capabilities (billing, scheduling, catalogue).
- Expose each module through a small public interface.
- Keep each module's data private; access it only through its interface.
- Enforce boundaries with code structure and automated checks.
- Communicate between modules with events where coupling should be loose.
Extracting a service later
Extract a module when there is a clear driver: a separate team, very different scaling needs, a different technology requirement or isolation for reliability or security. Because the module already has an interface and owns its data, extraction mainly changes in-process calls to network calls; plan for timeouts, retries and versioning. See API versioning and the strangler fig pattern.
Teams and Conway's law
Systems tend to mirror the communication structure of the teams that build them. A single team running ten microservices spends much of its time on operations; several teams sharing one tangled codebase step on each other. Align modules or services with team ownership, and revisit as the organisation grows.
Hypothetical example: a SaaS at two stages
This example is hypothetical. A workforce SaaS with eight engineers rebuilt its tangled application as a modular monolith with modules for accounts, scheduling, timesheets and billing. Two years later, with four teams, the scheduling engine needed heavy compute at roster publication time, so it was extracted as a separate service behind its existing interface, with queue-based communication. Everything else stayed in the monolith.
Common mistakes
- Starting with microservices for a small team.
- A 'distributed monolith' where services share a database.
- No module boundaries in the monolith.
- Extracting services without monitoring and tracing.
- Splitting by technical layer instead of capability.
Related guides
- Scaling SaaS applications for growth bottlenecks.
- Kubernetes vs serverless vs VMs for where to run it.
- Multi-tenant SaaS architecture for tenant data design.
- Monitoring and observability before distributing systems.
Conclusion
A modular monolith is the sensible default for most growing teams. Invest in boundaries and data ownership, and extract microservices only where team structure, scaling or isolation needs justify the operational cost.
Deciding on architecture for your product?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on SaaS and business application architecture and development. If it would help to review your options, we are happy to talk it through.
Common questions.
A single deployable application divided into well-defined modules with clear boundaries and interfaces, each owning its own data and logic. It keeps the operational simplicity of one deployment while avoiding the tangled code of an unstructured monolith.