A monolithic application is deployed as one unit. A microservices architecture separates capabilities into services that can be deployed independently and communicate through network interfaces. A monolith often reduces the initial delivery and operational burden; microservices can help when independent releases, ownership or scaling justify distributed-system complexity.
For a new product with a small team and changing requirements, a modular monolith is a practical starting option. For an established system, the right choice depends on measured constraints rather than the age of the technology or the size of the codebase alone.
What is monolithic architecture?
A monolith packages the application’s core functionality into one deployable unit. Its modules may cover accounts, orders, billing and reporting, with calls between them happening inside the application.
The frontend does not have to share that deployment. A separately deployed website or mobile app can communicate with a monolithic backend. The backend can also use several data stores or external services.
Frameworks do not decide the architecture: Laravel, Django.NET and Node.js can all support different deployment approaches. Microsoft’s overview of web application architectures provides examples of separating internal concerns within an application.
Advantages of a monolith
- Fewer deployment boundaries: One application release can update related functionality together.
- Simpler local development: Developers can often run and inspect the main application without coordinating multiple services.
- Direct module calls: Internal interactions avoid the additional network hop required between services.
- Simpler transactions where appropriate: Related changes within one transactional database can be committed together.
- Lower initial operational overhead: There are fewer independently managed runtime components.
Limitations of a monolith
- Changes share a release unit, so unrelated teams may need to coordinate deployments.
- Without enforced boundaries, dependencies can become tangled and changes harder to assess.
- Replicating the application generally scales the whole unit, even when one capability drives demand.
- Runtime faults can affect a broad part of the application.
A monolith is not inherently unmaintainable. Code organisation, testing and ownership influence these outcomes.
What is microservices architecture?
Microservices organise an application into separately deployable services around business capabilities. Services communicate through APIs or messages and control access to their own domain data.
Independence is the goal. If every change requires coordinated releases across several services, the system may retain the coupling of a monolith while adding network and operational complexity.
Microsoft’s microservices architecture guidance describes both the potential benefits and the operational demands of this approach.
Advantages of microservices
- Independent releases: Teams can deploy a capability without releasing the entire product, when interfaces remain compatible.
- Targeted scaling: Busy or resource-intensive services can receive additional capacity separately.
- Clear ownership: A team can take responsibility for a defined service through development and operation.
- Technology flexibility: A service can use a specialised implementation where its benefits justify the support burden.
- Potential fault isolation: Failures can be contained when dependencies and recovery behaviour are designed appropriately.
Limitations of microservices
- Network calls introduce latency, timeouts and partial failures.
- Cross-service changes require compatible interfaces and coordination.
- Debugging needs visibility across service boundaries.
- Distributed workflows complicate data consistency and recovery.
- More components create additional deployment, monitoring and support work.
Small services do not automatically create a simple overall system.
Monolith vs microservices: key differences
| Aspect | Monolith | Microservices |
|---|---|---|
| Deployment | One application release unit | Separately deployable services |
| Source organisation | Can contain many modules and packages | Can use a monorepo or separate repositories |
| Communication | Primarily in-process between internal modules | APIs or messages between services |
| Data | Often shared infrastructure; boundaries can still be enforced | Each service controls its data and access contracts |
| Scaling | Replicate the application; optimise supporting components | Scale selected services, subject to dependencies |
| Transactions | Local transactions can cover related operations | Cross-service workflows need explicit consistency and recovery design |
| Testing | Fewer runtime boundaries, but large suites can still be difficult | Service, contract, integration and selected end-to-end tests |
| Operations | Fewer independently operated components | More monitoring, deployment and incident coordination |
| Cost | Often a lower starting overhead | Additional overhead may be justified by targeted benefits |
| Team fit | Useful for a shared product and release ownership model | Useful when independent capability ownership is needed |
Repository count is not the deciding factor. Several services can live in one repository and still deploy independently; splitting code across repositories does not itself create microservices.
What is a modular monolith?
A modular monolith keeps one deployment while enforcing internal boundaries. Each module has defined responsibilities and interfaces, and other modules should not bypass those interfaces to change its internal state.
For example, an ordering system might separate catalog, orders, billing and fulfilment. These modules can remain in the same application without being allowed to depend on every internal detail of one another.
Useful practices include explicit public interfaces, module-level tests, clear data ownership and checks against unwanted dependencies. A directory structure alone does not establish these boundaries.
This approach allows the team to learn the domain without immediately introducing network calls between every capability. Martin Fowler’s Monolith First discussion explains why learning suitable boundaries can matter early in product development, while acknowledging that the approach is not universal.
Good boundaries can make later extraction easier. They do not remove the work of data migration, remote communication, deployment, monitoring and failure recovery. Remaining a modular monolith can also be a valid long-term choice.
Which architecture should you choose?
Consider a monolith or modular monolith when
- The product’s requirements and business boundaries are still changing.
- One team can comfortably own delivery and operations.
- Related features benefit from coordinated transactions and releases.
- The workload can meet its targets without independent service scaling.
- Introducing more runtime components would stretch the team’s support capacity.
High traffic alone does not rule out a monolith. Application instances, database tuning, caching and asynchronous processing can address many bottlenecks without a complete architectural change.
Consider microservices when
- Release coordination repeatedly blocks teams with distinct responsibilities.
- A capability has a proven need for different capacity or deployment frequency.
- Business boundaries and data ownership are sufficiently understood.
- Teams can operate their services, not just write them.
- The expected benefit exceeds migration and ongoing operational costs.
Use a readiness review rather than a rule based on developer count or monthly users. Microsoft’s microservices assessment guidance is a useful starting point for examining these conditions.
How should data work across services?
Service ownership means other services should not freely read and update its internal tables. Expose supported APIs or events instead of making a shared schema the integration contract.
This does not always require a separate physical database server per service. Logical separation may be possible on shared infrastructure, but permissions, resource contention, maintenance and failure exposure still need consideration.
Cross-service workflows need a business decision about consistency. Some updates can arrive later; others must be confirmed before the user proceeds. A saga can coordinate steps and compensating actions, but compensation is not the same as rolling back one database transaction.
Microsoft’s data considerations for microservices discusses the difficulties created by distributed data ownership. Design these workflows before separating services, particularly where orders, inventory and payments interact.
Which architecture costs less?
There is no reliable fixed price difference between the two. Compare the total cost of delivering and operating the same workload to the same service targets.
| Cost factor | What to assess |
|---|---|
| Development | Domain design, interfaces, testing and developer setup |
| Infrastructure | Compute, databases, queues, networking and idle capacity |
| Operations | Deployment tooling, observability, incident response and recovery |
| Change delivery | Release coordination, regression effort and compatibility work |
| Migration | Data movement, temporary duplication, validation and cutover |
A small product may gain little from maintaining many services. An established platform may justify that overhead if independent delivery or targeted capacity resolves a costly constraint. Estimate both cases with your own workload and team.
Migrating from a monolith to microservices
Do not start by deciding how many services to create. Start with the problem you need to solve.
- Measure the constraint. Record release delays, resource bottlenecks or incident impact.
- Clarify the boundary. Identify the capability, its dependencies and its data owner.
- Choose one extraction candidate. Prefer a bounded change whose outcome can be measured.
- Prepare operation and recovery. Establish deployment, monitoring, access control and rollback procedures before moving production traffic.
- Plan data transition. Define the source of truth, migration validation and treatment of writes during cutover.
- Shift traffic gradually where possible. Verify correctness and service targets before retiring the old path.
- Review the result. Continue only if the benefits justify the added complexity.
The Strangler Fig pattern supports incremental replacement by routing selected functionality to a new implementation while other functionality remains in the original system.
Rolling back traffic alone may not restore data already changed by the new service. Treat data compatibility and recovery as part of the migration design.
A practical example: an order-management platform
Imagine an initial product covering catalog, orders, billing and reporting. One team owns it, and changes often span several of these capabilities. A modular monolith is a reasonable starting hypothesis.
Later, suppose report generation becomes resource-intensive and has a different release schedule. First investigate query design, workload scheduling or background processing. If a separate reporting service offers a measurable benefit, define how it receives data and what reporting delay is acceptable before extracting it.
This does not require splitting every remaining module. A mixed system can be an intentional result.
Frequently asked questions
Are microservices better than monolithic architecture?
Not universally. They can support independent deployment and scaling, but add distributed-system responsibilities. Choose them for a clear benefit that your team can operate and measure.
Can a monolith scale horizontally?
Yes. Multiple application instances can run behind a load balancer when state and supporting services are designed appropriately. Database capacity, sessions and background work also need attention.
Does every microservice need its own repository and database server?
No. Repositories are a source-management choice. Data ownership is a logical boundary; physical infrastructure choices depend on isolation, security, capacity and operational requirements.
Do microservices require Kubernetes?
No. Kubernetes is one deployment option, not part of the definition. Select a hosting approach that supports the required deployment and operational behaviour without unnecessary complexity.
Can I start with a monolith and extract services later?
Yes. Clear module interfaces and data ownership can help, but extraction still requires distributed workflow design, operational tooling and careful migration. It is an option rather than an inevitable upgrade.
How many microservices should a product have?
There is no ideal number. Define boundaries around justified business and operating needs. If services constantly change together, reconsider whether separating them is useful.
Choose an architecture your team can deliver and operate
Appther helps businesses assess backend structure, integration requirements and modernisation options through its enterprise software development and cloud managed services.
Start with the constraints your product faces today, then choose an architecture that supports its next stage of growth.
