Few software decisions cause as much debate as the choice between a monolith and microservices. For years, microservices were presented as the modern default, used by companies such as Netflix, Amazon, and Uber. Then teams started sharing stories about moving back to simpler designs, making the conversation more balanced.
Neither approach is universally better. Each solves particular problems and introduces others. This guide compares both architectures and introduces a third option: the modular monolith.
Key Takeaways
- A monolith is one deployable application; microservices consist of independently deployable services.
- Monoliths are generally simpler and cheaper to build, test, and operate.
- Microservices help large organisations scale teams and components independently but add operational complexity.
- A modular monolith offers clear internal boundaries without distributed-system overhead.
- Choose based on team size, domain clarity, scalability, and operational maturity.
What Is a Monolith?
A monolithic application is built and deployed as a single unit. The user interface, business logic, and data access code live in one codebase and usually share one database.
A monolith does not have to be poorly organised. It can contain clear modules for billing, customers, and orders. Its defining feature is that the whole application is deployed together.
Frameworks such as Ruby on Rails, Django, Laravel, and ASP.NET make monoliths quick to build. Shopify has also discussed restructuring its core monolith in its article on deconstructing the monolith.
What Are Microservices?
Microservices structure an application as a collection of small, independent services. Each service handles a business capability, such as payments, search, or notifications.
- Runs in its own process.
- Can be deployed independently.
- Usually owns its own data store.
- Communicates with other services through APIs or messages.
Martin Fowler and James Lewis explain this architecture in their introduction to microservices. The central idea is to organise services around business capabilities and give teams greater autonomy.
Monolith vs Microservices at a Glance
| Factor | Monolith | Microservices |
|---|---|---|
| Deployment | One unit, deployed together | Services deployed independently |
| Development speed | Usually faster initially | More setup required |
| Operational complexity | Low | High |
| Infrastructure cost | Usually lower | Usually higher at small scale |
| Scaling | Scale the whole application | Scale individual services |
| Team structure | Suitable for one or a few teams | Suitable for many independent teams |
| Testing | Simpler end-to-end testing | Contract and integration testing required |
| Fault isolation | One bug can affect the whole application | Failures can be contained with proper design |
| Technology choice | Usually one main technology stack | Different stacks can be used per service |
| Data consistency | Simpler transactions in one database | Distributed data and eventual consistency |
The Benefits of a Monolith
Simplicity
One codebase, one build, and one deployment mean less operational overhead. Developers can run the application locally, trace requests, and debug problems in one place.
Speed in the Early Stages
When product requirements change frequently, a monolith makes it easier to modify features and interactions without coordinating multiple services and deployments.
Lower Costs
A monolith usually requires fewer servers, databases, and operational tools. See our guide to cloud cost optimisation for more on controlling infrastructure costs.
Easier Data Consistency
A shared database allows ordinary transactions. For example, updating an order and its payment status together is straightforward.
Performance
Calls between modules can happen in memory. Microservice calls travel over a network, adding latency and potential points of failure.
The Drawbacks of a Monolith
- Coupling over time: Poorly defined modules can become tangled.
- Slower deployments: Large builds and test suites can make releases slower.
- Scaling limitations: The entire application may need scaling even when only one feature requires more capacity.
- Team bottlenecks: Shared releases can increase coordination costs.
- Technology lock-in: Framework or language upgrades can affect the entire application.
These challenges tend to emerge as the codebase and engineering team grow. Many businesses never reach that scale.
The Benefits of Microservices
Independent Deployment
Teams can release their services without waiting for other teams, reducing coordination across large engineering organisations.
Team Autonomy and Ownership
Teams can own services from development through production. This relates to Conway’s law, which observes that software architecture often reflects the communication structure of the organisation. Read more on Mel Conway’s website.
Targeted Scaling
If search or checkout requires significantly more capacity than the rest of the application, you can scale that service independently.
Fault Isolation
Timeouts, retries, and fallbacks can help prevent a failure in one service from bringing down the entire system.
Technology Flexibility
Teams can choose different languages, databases, or frameworks when specific requirements justify them.
The Drawbacks of Microservices
Microservices replace some forms of complexity with others, especially around networking, deployment, and data management.
- Distributed-system problems: Network failures, latency, and retries require careful handling.
- Operational overhead: Automated deployment, logging, monitoring, tracing, and alerting become essential.
- Data management: Cross-service workflows may require events, sagas, and eventual consistency.
- Testing complexity: Contract tests and integration environments are important.
- Higher costs: Additional services increase compute, networking, and tooling requirements.
- Security surface: Each service and API introduces additional security considerations. See our SaaS security checklist.
Amazon Prime Video’s video quality monitoring team described moving one monitoring tool from a distributed design to a single process in 2023. The team reported infrastructure cost reductions of over 90% for that tool. This was not a migration of all Prime Video, but it illustrated the costs that distribution can introduce. Read the DevClass report.
The Middle Ground: The Modular Monolith
A modular monolith is a single deployable application with strong internal boundaries. Modules such as billing, catalogue, and accounts have clearly defined responsibilities and interfaces.
- Each module has a clear public interface.
- Internal implementation details remain hidden.
- Data ownership is separated where practical.
- Teams can own specific modules.
This approach offers many organisational benefits of microservices while retaining the operational simplicity of a monolith. Clear boundaries also make it easier to extract a module into a separate service if future requirements justify it.
Martin Fowler discusses a related strategy in MonolithFirst.
How to Keep a Monolith Modular
- Organise code by business capability, such as billing and orders.
- Define module interfaces and prevent direct access to other modules’ internals.
- Enforce boundaries using architecture tests and dependency rules.
- Separate data ownership through module-specific tables or schemas.
- Use internal events where they reduce coupling between modules.
How to Decide: Key Questions
1. How Big Is Your Engineering Team?
A team of five to fifteen developers can often work effectively in a well-structured codebase. Microservices become more attractive when many teams need to develop and release independently.
2. How Well Do You Understand Your Domain?
If you are still discovering product requirements and domain boundaries, splitting into services too early can lock in poor architectural decisions.
3. Do Parts of the System Have Different Scaling Needs?
A component with significantly different traffic, hardware, or availability requirements may justify a separate service. AI inference is one example. See our guide to the cost of running AI in production.
4. How Mature Is Your Operational Capability?
Microservices require reliable automation, monitoring, and incident response. If continuous delivery is not yet reliable, establish those foundations first. Read our guide to DevOps for small teams.
5. What Are Your Compliance and Isolation Needs?
Sensitive workloads, including payment processing and personal data handling, may benefit from separate services with stricter controls. However, a well-designed modular monolith can also meet many isolation requirements.
A Simple Decision Guide
| Your Situation | Recommended Starting Point |
|---|---|
| New product, small team, changing requirements | Modular monolith |
| Established product, one to three teams | Modular monolith; extract services when justified |
| Many teams blocked by shared releases | Gradually extract services along stable boundaries |
| One component has different scaling or technology needs | Monolith plus one or two separate services |
| Large organisation with mature platform and DevOps | Microservices may be appropriate |
Many real systems are hybrids: a core application combined with separate services for file processing, search, notifications, or AI inference. This is a practical and valid approach.
Migrating From a Monolith to Microservices
If you decide to move towards services, do it gradually.
- Start with clear reasons. Identify specific problems such as release bottlenecks or scaling limitations.
- Modularise first. Establish clear boundaries inside the existing application.
- Use the strangler fig pattern. Move selected functionality to a new service while the rest remains in the monolith. Learn more about the strangler fig application pattern.
- Extract one service at a time. Start with a well-bounded, lower-risk component.
- Invest in the platform. Establish automated deployment, logging, monitoring, and tracing.
- Design APIs carefully. Review our guide to REST vs GraphQL.
- Measure results. Track deployment frequency and change failure rate.
Common Mistakes to Avoid
- Splitting services before understanding the domain.
- Creating a distributed monolith with tightly coupled services.
- Sharing one database across services and recreating data-layer coupling.
- Making services too small and increasing cross-service dependencies.
- Underestimating monitoring and on-call responsibilities.
- Copying large-company architectures without having similar needs or resources.
What About Serverless?
Serverless functions are another way to split functionality into independently deployed components while the cloud provider manages the underlying servers and scaling. They work well for event-driven tasks and uneven workloads but share some trade-offs with microservices. Read our guide to serverless computing.
Architecture Is Also a Build vs Buy Decision
Before designing a new component, consider whether you need to build it at all. Payments, authentication, email delivery, and search may be better handled by managed services.
Our guide to build vs buy software explains the decision framework. You can also read our guide to writing a software requirements document before selecting an architecture.
Conclusion
The monolith vs microservices debate is about matching architecture to your organisation and its needs. Start with a modular monolith that has clear internal boundaries, automated tests, and reliable deployment. Extract services when a specific need justifies it, and invest in the platform and practices required to operate distributed systems effectively.
This approach helps control costs, keeps development moving, and leaves room for your architecture to evolve as your business grows.
Kaushal’s note:
In my opinion, a modular monolith is often the smartest starting point for new software and AI projects. It keeps development simpler, reduces infrastructure costs and gives teams more time to focus on building useful features. Microservices make sense when genuine scaling, performance or team coordination challenges arise. I believe good software architecture is not about following trends, but choosing what works best for the business today while leaving room to grow tomorrow.
