What Is a Monolith?
Imagine a café where one kitchen handles everything: taking orders,
preparing food, managing payments, and tracking inventory. All functions
work together as one system.
In software, a monolithic architecture is an application where
different features are built as part of one application and are
typically packaged and deployed together.
For example, an e-commerce application might include user login, product
catalog, shopping cart, payments, and orders. These features can still
be organized into separate modules; the key point is that they are
usually deployed as one application.
What Are Microservices?
Now imagine the café grows into a food court. One team manages orders,
another handles payments, another manages inventory, and another handles
delivery. Each team operates its own service and communicates with other
services when needed.
In software, microservices architecture splits an application into
smaller, independently deployable services, each responsible for a
specific business capability.
An e-commerce application could have user, product, order, payment, and
inventory services. Each service can be deployed and scaled
independently. Services often own their data and communicate through
APIs or messages, depending on the design.
Monolith vs. Microservices
Feature Monolith Microservices
Structure One application Multiple independent
services
Deployment Usually deployed Services can be
together deployed separately
Development Simpler initially More coordination and
infrastructure
Scaling Often scale the Scale individual
application as a whole services
Failure handling A failure can affect Failures can be
the whole application isolated, but not
automatically
Communication Often in-process Network calls or
function calls messages
Data management Often one shared Services own data where
database appropriate
Best fit Early products and many Systems needing
small-to-medium systems independent scaling or
team ownership
Advantages of a Monolith
1. Simpler to Build
The codebase and deployment process are often easier to understand when
starting a new product.
2. Easier Local Development and Testing
Developers can run much of the application in one place, and function
calls within the application do not need network communication.
3. Straightforward Transactions
When related data is stored in one database, transactions across related
operations can be easier to implement.
4. Lower Operational Overhead
You may need fewer deployment pipelines, monitoring configurations, and
infrastructure components.
Disadvantages of a Monolith
1. Scaling Can Be Less Targeted
If order processing receives heavy traffic but inventory does not, you
may have to scale the entire application even when only one part needs
more resources.
2. Releases Can Be Coupled
A small change in one module may require deploying the whole
application, depending on the architecture and deployment setup.
3. The Codebase Can Become Hard to Maintain
Without clear module boundaries, features can become tightly coupled and
changes can affect unexpected parts of the system.
A monolith is not automatically poorly designed. A modular monolith
with clear boundaries can remain maintainable for a long time.
Advantages of Microservices
1. Independent Scaling
If the order service receives much more traffic than the product
service, you can scale the order service without scaling every other
service.
2. Independent Deployment
Teams can release a service separately when its interfaces and
compatibility are managed carefully.
3. Clear Ownership
Teams can own specific business capabilities, code, and operational
responsibilities.
4. Technology Flexibility
Different services can use different technologies when there is a real
reason to do so. This flexibility also introduces more maintenance work.
Disadvantages of Microservices
1. More Operational Complexity
You need to manage service discovery, deployment, configuration,
observability, security, and networking across multiple services.
2. Network Failures
A service call can time out or fail even when the calling service is
healthy. Systems need timeouts, retries, and sometimes circuit breakers.
3. Data Consistency Is Harder
A business operation may involve several services and databases.
Distributed transactions are complex, so systems often use eventual
consistency, events, or sagas where appropriate.
4. Debugging Can Be Harder
A single user request may travel through several services. Distributed
tracing and centralized logs can help teams understand what happened.
5. More Infrastructure and Cost
Each service needs appropriate deployment, monitoring, scaling, and
operational support. For a small team, this overhead may outweigh the
benefits.
When Should You Use a Monolith?
A monolith is often a good choice when: - You are building an MVP or a
new product. - The team is small. - Requirements are changing
frequently. - You want simpler testing, deployment, and debugging. - You
do not yet need independent scaling for different features.
A good starting point is often a modular monolith: one deployable
application, with clear boundaries between business modules.
When Should You Use Microservices?
Microservices may be a better fit when: - Different parts of the
application have very different scaling needs. - Multiple teams need to
release services independently. - The product has clear business
boundaries. - The organization can manage distributed systems,
monitoring, networking, and failure recovery. - The benefits of
independent ownership and deployment outweigh the added complexity.
Do not choose microservices only because the company is growing or
because they sound more modern. Choose them to solve concrete problems.
How Can a Monolith Evolve into Microservices?
Imagine your café becomes extremely popular. Initially, one kitchen
handles everything. Later, online orders increase dramatically, but
inventory management remains small.
You could extract order processing into its own service so it can scale
independently. Over time, other capabilities might be separated when
there is a clear benefit.
A common migration approach is the Strangler Fig pattern: new
functionality is built outside the old system, and capabilities are
gradually moved over until the old implementation can be retired. This
should be done incrementally, with clear service boundaries and a safe
migration plan.
Example: An E-Commerce Application
Monolithic Design
A single application contains login, product catalog, cart, orders,
payments, and inventory modules. The modules may share a database and
are deployed together.
Microservices Design
Separate services manage users, products, orders, payments, and
inventory. The order service may call the payment service and
communicate with inventory through an API or message queue.
This creates independent deployment and scaling options, but also means
teams must handle network failures, duplicate messages, and consistency
between services.
Quick Interview Question
Question: If you were building a new e-commerce application today,
would you choose a monolith or microservices?
Sample answer:
"I would start with a modular monolith unless there were clear
requirements for independent deployment, scaling, or team ownership. It
keeps the initial architecture simpler and helps the team validate the
product. As the application grows, I would extract services based on
measurable bottlenecks and clear business boundaries rather than
splitting everything from day one."
Follow-Up: Can a Monolith Handle Millions of Users?
Yes, depending on the workload, architecture, infrastructure, and
optimization. A monolith can be replicated across multiple servers and
use caching, load balancing, and database scaling. User count alone does
not determine whether microservices are necessary.
Follow-Up: Are Microservices More Reliable?
Not automatically. They can isolate some failures, but they also
introduce network dependencies and more failure modes. Reliability
depends on architecture, observability, timeouts, retries, capacity
planning, and operational practices.
Key Takeaway
- Monolith: One application, usually deployed as a unit.
- Microservices: Multiple independently deployable services working together.
- Best practice: Choose the simplest architecture that meets current needs, keep boundaries clear, and evolve the design as real requirements emerge.
Top comments (0)