In short
Most new products should begin as a modular monolith: one deployable system with clear internal boundaries. Choose microservices when independently owned domains genuinely need separate deployment, scaling, reliability, technology, or security boundaries—and the team can operate distributed data, networking, observability, testing, and incidents.
The default: a modular monolith
A monolith is one deployable application. It does not need to be an unstructured codebase. Separate domains, modules, interfaces, and ownership inside it while keeping transactions, local calls, testing, and deployment simple.
Microservices split capabilities into independently deployed network services. That independence adds operational and data complexity immediately.
Comparison
| Modular monolith | Microservices |
|---|---|
| One deployment and common runtime | Independent deployments |
| Simpler transactions and local calls | Distributed data and network failures |
| Easier local development and testing | Stronger service isolation when mature |
| Good for small, changing teams | Useful for several autonomous teams |
| Scale the application or selected processes | Scale services independently |
Choose a monolith when
- the domain is still changing;
- one or two teams own the product;
- traffic and scaling patterns are uncertain;
- transactions cross several concepts;
- rapid feature learning matters;
- operational capacity is limited.
Keep boundaries explicit so a service can be extracted later if evidence justifies it.
Choose microservices when
- several teams need independent release ownership;
- domains and interfaces are stable enough;
- one capability has materially different scaling;
- fault or security isolation creates concrete value;
- separate technology is required by the problem;
- the organisation already operates distributed systems well.
Costs teams underestimate
- service discovery and networking;
- identity between services;
- distributed tracing and logs;
- retries, timeouts, idempotency, and partial failure;
- data ownership and eventual consistency;
- contract and end-to-end testing;
- local development environments;
- deployment coordination and incident response.
Microservices move complexity from code boundaries into the operating system of the organisation.
Extraction rule
Extract a service when the boundary is understood and independent deployment, scale, reliability, or ownership pays for the new failure surface. Do not extract merely because a module has many lines.
Common questions
Are microservices more scalable?
They allow independent scaling, but a well-designed monolith can handle substantial use. Database, caching, queries, and operations often matter first.
Is a monolith technical debt?
No. An unstructured monolith can create debt; a modular monolith is a deliberate architecture with simpler operations.
Can a monolith be split later?
Yes, especially when domain boundaries, interfaces, and data ownership are clear. Extraction still requires migration and operational work.
How many teams justify microservices?
There is no count, but independent team ownership is a stronger reason than application size. One small team usually gains little from many services.
Should an MVP use microservices?
Usually not. Use them only when the MVP specifically tests or requires a distributed boundary that cannot be represented responsibly in one application.
