As applications grow, one of the biggest architectural decisions is whether to keep everything in a single application (Monolith) or split it into independent services (Microservices).
Most startups begin as a Monolith and gradually move toward Microservices as scale, team size, and business complexity increase.
Monolithic Architecture
What is it?
A Monolithic Architecture is a single application where all business functionalities are developed, deployed, and managed together.
Everything runs inside one codebase and one deployment unit.
How Does It Work?
Monolithic Application
+---------------------------------------------------+
| |
| User Service |
| Product Service |
| Order Service |
| Payment Service |
| Notification Service |
| |
+---------------------------------------------------+
|
V
Single Database
All modules share:
- Same codebase
- Same deployment
- Usually same database
Real World Example
Early Amazon
Initially Amazon was a large monolithic application.
Features like:
- Product Catalog
- Orders
- Payments
- Shipping
were all part of the same application.
Advantages
Easy Development
Everything is in one place.
Developers can easily navigate the codebase.
Easy Deployment
Only one application needs deployment.
Simpler Testing
End-to-end testing is easier.
Lower Initial Cost
Perfect for startups and MVPs.
Disadvantages
Difficult Scaling
If only Order Service requires scaling:
Entire Application
must be scaled
Slower Deployments
Small changes require deploying the entire application.
Large Codebase
As features grow:
100k+ lines
500k+ lines
Millions of lines
maintenance becomes difficult.
Single Point of Failure
One issue can impact the entire system.
Interview One-Liner
A Monolithic Architecture packages all business functionalities into a single deployable application.
Microservices Architecture
What is it?
Microservices Architecture breaks an application into multiple independent services.
Each service:
- Owns a specific business capability
- Has its own deployment lifecycle
- Can scale independently
How Does It Work?
Client
|
V
API Gateway
|
------------------------------------------------
| | | |
V V V V
User Service Order Service Payment Service Product Service
| | | |
V V V V
User DB Order DB Payment DB Product DB
Each service is responsible for its own business domain.
Real World Example
Netflix
Netflix has hundreds of microservices.
Examples:
- Recommendation Service
- User Service
- Billing Service
- Streaming Service
- Search Service
Each service can scale independently.
Advantages
Independent Deployment
Deploy one service without touching others.
Independent Scaling
Scale only the services experiencing heavy traffic.
Better Fault Isolation
If Recommendation Service fails:
Video Streaming
still works
Technology Flexibility
Different services can use different technologies.
Java
Go
Node.js
Python
Disadvantages
Increased Complexity
Managing many services is harder.
Network Calls
Communication happens over network.
Service A -> Service B
which introduces latency.
Distributed Data Challenges
Maintaining consistency becomes difficult.
DevOps Overhead
Requires:
- Monitoring
- Logging
- Service Discovery
- API Gateway
- Container Orchestration
Interview One-Liner
Microservices Architecture divides an application into independently deployable services organized around business capabilities.
Evolution Towards Microservices
Most companies follow these phases.
Phase 1: Monolith
Users
|
V
Monolithic Application
|
V
Database
Best for:
- MVPs
- Early startups
Phase 2: Modular Monolith
Application remains one deployment but code is separated into modules.
Application
├── User Module
├── Product Module
├── Order Module
└── Payment Module
This prepares the system for future extraction.
Phase 3: Service Extraction
Frequently changing modules are extracted first.
Monolith
|
|
+----> Payment Service
Common candidates:
- Authentication
- Notifications
- Payments
Phase 4: Hybrid Architecture
Some functionality remains in monolith.
Some functionality becomes microservices.
Monolith
|
+---- User Service
|
+---- Payment Service
This stage is common in growing companies.
Phase 5: Full Microservices
User Service
Order Service
Payment Service
Inventory Service
Notification Service
All services operate independently.
Interview One-Liner
Most organizations migrate gradually from Monolith → Modular Monolith → Hybrid Architecture → Microservices.
Decomposition Patterns
What is Decomposition?
Decomposition is the process of breaking a large monolithic application into smaller services.
This is one of the most important topics in Microservices interviews.
1. Decompose by Business Capability
Services are created around business functions.
Example: E-Commerce
E-Commerce System
├── User Service
├── Product Service
├── Cart Service
├── Order Service
├── Payment Service
└── Notification Service
Each service owns a business capability.
Why It Works?
Teams align with business domains.
Order Team
Product Team
Payment Team
Each team owns its service.
Most Common Pattern
This is the preferred decomposition strategy.
Large companies use this approach extensively.
Real Example
Amazon
Catalog Service
Checkout Service
Payment Service
Inventory Service
Each service represents a business capability.
Interview One-Liner
Business Capability decomposition organizes services around business functions rather than technical layers.
2. Decompose by Subdomain (DDD)
Based on Domain Driven Design.
Business is divided into bounded contexts.
Example: Banking
Banking System
├── Customer Domain
├── Account Domain
├── Loan Domain
├── Card Domain
└── Payment Domain
Each domain becomes an independent service.
Benefits
- Clear ownership
- Strong boundaries
- Better maintainability
Interview One-Liner
Domain decomposition creates services around bounded business domains and is commonly used with Domain Driven Design.
3. Decompose by Resource
Services are organized around resources.
Example
User Resource
Product Resource
Order Resource
becomes
User Service
Product Service
Order Service
This works well for CRUD-heavy systems.
Interview One-Liner
Resource-based decomposition creates services around core business entities.
4. Strangler Pattern
One of the most important migration patterns.
Instead of rewriting the entire monolith:
- Extract one service at a time
- Route traffic gradually
- Replace old functionality slowly
Example
Client
|
V
API Gateway
|
---------------------
| |
V V
Monolith Payment Service
Later:
Payment Service
User Service
Order Service
continue replacing monolith functionality.
Why Companies Use It?
Large applications cannot be rewritten overnight.
Netflix, Amazon, and many enterprises use gradual migration.
Interview One-Liner
The Strangler Pattern gradually replaces parts of a monolith with microservices without requiring a full rewrite.
Monolith vs Microservices
| Feature | Monolith | Microservices |
|---|---|---|
| Deployment | Single | Multiple |
| Scalability | Whole App | Per Service |
| Complexity | Low | High |
| Development Speed | Faster Initially | Slower Initially |
| Fault Isolation | Poor | Better |
| Team Independence | Limited | High |
| Technology Flexibility | Low | High |
| Operational Overhead | Low | High |
When Should You Use Monolith?
Use Monolith when:
- Startup or MVP
- Small team
- Limited traffic
- Fast delivery required
When Should You Use Microservices?
Use Microservices when:
- Large engineering teams
- Millions of users
- Independent deployments required
- Different scaling requirements exist
Quick Revision
Monolith
One Application
One Deployment
Usually One Database
Microservices
Many Services
Independent Deployments
Independent Scaling
Migration Path
Monolith
↓
Modular Monolith
↓
Hybrid Architecture
↓
Microservices
Important Decomposition Patterns
Business Capability
Domain Driven Design
Resource Based
Strangler Pattern
Interview Summary
Monolithic architecture is simple, easy to develop, and ideal for startups, but becomes difficult to scale and maintain as systems grow. Microservices solve these problems by breaking applications into independently deployable services. The most common decomposition strategy is by business capability, while the Strangler Pattern is widely used to migrate gradually from a monolith to microservices without a complete rewrite.